Patent Grant
12080162
The present invention relates to traffic information coding and transmission, and in particular to a method of increasing the geospatial resolution of traffic information by dividing known location intervals into a fixed number of sub-segments, efficient coding of the traffic information, and the distribution of the traffic information to end-user consuming devices over a satellite based broadcast transport medium.
Various proposals have been presented for improving the accuracy of traffic information broadcast over a communications channel. The currently-accepted RDS/TMC standard uses a coding method called Alert-C which allocates identifiers to fixed points on the ground and to the segments of roadway the run between those points. An alternative standard, called TPEG, supports the TMC model and also arbitrary points identified by geographic (longitude/latitude) coordinates or by free text that can be used in conjunction with a mapping database (e.g. “W 54th St, New York”). An additional proposal has been made where the Alert-C format is enhanced by means of a “Precise Location Reference (PLR)” which indicates a point, and an extent from that point, in distance units (e.g. yards or miles) from one of the pre-defined location points.
Both of these proposals, TPEG and PLR, suffer from a number of disadvantages when applied to a broadcast distribution medium such as a satellite radio channel.
What is needed in the art are improved systems and methods for obtaining and processing accurate traffic information so that such information may be broadcast to users over a communications channel.
It is noted that the U.S. patent or application file contains at least one drawing executed in color. Copies of this patent or patent application publication with color drawings will be provided by the U.S. Patent Office upon request and payment of the necessary fee.
Systems and methods are provided for increasing the geospatial resolution of traffic information by dividing known location intervals into a fixed number of sub-segments not tied to any one map providers format, efficient coding of the traffic information, and distribution of the traffic information to end-user consuming devices over one or more of a satellite based broadcast transport medium and a data communications network. Exemplary embodiments of the present invention detail a nationwide traffic service which can be encoded and distributed through a single broadcast service, such as, for example, an SDARS service, or a broadcast over a data network. Exemplary embodiments include aggregating the traffic data from segments of multiple location intervals, into predefined and predetermined flow vectors, and sending the flow vectors within a data stream to users.
Exemplary embodiments of the present invention detail a high resolution nationwide traffic service which can be encoded and distributed through a single broadcast service, such as, for example, the SDARS services provided by Sirius XM Radio Inc.
In exemplary embodiments of the present invention, the following novel approaches and coding techniques may be used:
In exemplary embodiments of the present invention, confidence levels obtained from raw traffic data (along with speed and congestion data) can both (i) be disclosed to drivers/users to supplement a very low signal (or no signal) speed and congestion report, and (ii) can also be used in various system algorithms that decide what local anomalies or aberrations to filter out as noise, or to disclose as accurate information and thus more granularly depict the roadway in question (and use additional bits to do so) as an actual highly localized traffic condition.
Exemplary embodiments of the present invention eliminate various disadvantages from the conventional approaches described above. In particular, the TPEG proposal requires a large number of bits to encode location references, typically between 10 and 100 times what this invention requires. The TPEG coding scheme is a severe disadvantage when transmitting traffic information over a bandwidth-constrained channel.
Moreover, PLR or offset references are not independent of a map database. Since different maps may calculate the length of a road differently, the same length offset will appear at different places on different maps. If the encoding system is tied to a specific map database, this is a disadvantage for systems that choose to obtain their maps from a different vendor.
Additionally, named streets or places are typically only used in apparatus that also contains a full street atlas which limits their use to the more expensive ‘full navigation unit’ systems in vehicles.
Finally, the Alert-C encoding method limits the amount of information to simple predefined events or phrases. This invention provides the ability to transmit free text descriptions of the traffic events thereby providing additional valuable commentary information to supplement encoded event values.
Various exemplary embodiments of the present invention solve these problems, and provide for a robust nationwide traffic service which can be encoded and distributed through a single broadcast service.
It is noted that in what follows a particular exemplary embodiment is described in detail. It is often referred to as either “Apogee” or “Apogee Traffic” which is the internal name used by Applicant for this technology. The described Apogee system is only exemplary, and any element of it is also understood to be exemplary. Moreover, because the Apogee technology was developed for Applicant, there are numerous references to aspects of Applicant's satellite broadcast service, including its various data services which are auxiliary to its digital audio service, including its legacy traffic data service. The interactions of Apogee with these services, and their various standards, protocols and conventions are also all exemplary, the disclosed invention not being limited to any particular embodiment. For ease of reading what follows, the exemplary and illustrative nature of Apogee, Apogee Traffic, or a service or component of the Sirius XM Radio Inc. SDARS or data service (referred to as “SXM”, “SXM service”, etc.) will not be repeated each time such a reference is made. It being understood as a global fact.
The following specification includes three parts. A first part, Part I, which includes an exemplary protocol and implementation, and general description of the invention. A second part, Part II, which includes an exemplary overall architecture and proposed implementation of the Apogee Traffic Service, and finally a third part, Part III, which describes an exemplary interface to the Apogee Traffic service.
Part I—Protocol and Implementation
The following defines a protocol and implementation of the transmission of an exemplary embodiment of the Apogee Traffic Service, and also provides guidance for the reception and decoding of the data for a receiving product.
Number Formatting
This specification uses the following notations to indicate the numbering system base of the displayed number:
The following acronyms will be used in the description:
The following are separate documents and resources, referenced by this specification and/or useful to product developers implementing the Apogee Traffic service. Numbers in brackets, e.g. [1], are used elsewhere in this specification to refer to these documents and resources.
Apogee is a next-generation traffic-based service, which is contemplated to be provided by Sirius XM Radio. Based on over seven years of real-world experience with the TMC/Alert-C based traffic data service, SiriusXM has developed the new ground-up Apogee service that eliminates several constraints in the current TMC/Alert-C standard and improves upon the new TPEG standard. Although much of what follows describes an exemplary embodiment contemplated to be provided by Sirius XM Radio Inc., this is understood to be in no way limiting, and various exemplary embodiments in various contexts are all included.
In exemplary embodiments of the present invention, there may be four key elements to Apogee technology:
The service is usable in vehicles without a GPS system; the system may display traffic information around a fixed location specified by the user (for example using a city name or selecting a point on a map display). For systems with GPS information data, the system may display traffic information around the vehicle's current location, automatically adjusting the extent of the information presented as the vehicle moves. For systems with full navigation (routing) capabilities; the traffic data may be used to estimate travel times, and make better estimates for arrival times by taking into account the time of day, and using both current and predicted future traffic conditions.
This Part I is divided into two major parts. A first portion describing the features of the Apogee Protocol and how those features can be used to create a full traffic service by a product or application, and a section portion describing how to decode an exemplary bitstream protocol transmitted over an exemplary satellite data stream to extract the service elements required in the first portion.
Apogee and Existing Standards
Apogee uses elements from existing traffic protocols to leverage existing work and to promote the reuse of software that is already based on these standards.
Although Apogee leverages existing standards where it can, the transmission format is completely unrelated to either RDS-TMC or TPEG. The reason for doing this is to support more service elements than are defined by RDS, while avoiding the excessive decoding burden of TPEG. It is noted that:
These concepts are developed further in the following sections.
Service Elements
The complete Apogee traffic service is built up from a set of service elements, not all of which need to implemented for every system.
Table 1 shows the individual service elements present in Apogee traffic. The eight elements marked by a ✓ are explicitly transmitted as part of the protocol. x elements are not currently supported and [✓] elements are implicitly supported by their effect on the road or ramp S/F elements. Some service elements, for example predictive ramp speed and flow, may be introduced over time while others, for example the ability to forecast accidents, do not make sense.
Service Elements by Time
The service elements may be further divided by time:
Table 1 also indicates, with the x mark, that in various embodiments, not all time-based components are present for all services.
Road S/F
The road S/F service elements contains both speed and flow information for more than 300,000 roadway miles of major highways and arterials across most of the United States and Canada. There are two types of information presented by the service:
Unlike transit times, which are calculated, congestion values are perceived quantities related to the “out of the window” driver experience. They are affected by traffic density and posted speed limits. In exemplary embodiments, all the available information for a road segment may be aggregated to determine its perceived congestion level and encoded this as a small integer which can be used to color the traffic map.
Ramp S/F
The ramp S/F service element provides Speed and Flow data for on- and off-ramps used to connect other roadways to the major Controlled-Access highways such as freeways and interstates. The service supports all the Controlled-Access-to-Controlled-Access ramps and many of the intersections between Controlled-Access roads and other major highways. Ramp locations that are coded in the TMC tables are represented using that encoding, while the additional ramps defined for Apogee are encoded as described below.
The information can be used to color a map or to suggest alternative routes when a particular exit or entrance is reported as being heavily congested.
Construction
The construction service element provides information about actual and planned roadworks along more than 1,000,000 roadway miles in the United States and Canada. Information includes the extent of the affected roadway, the impact on traffic, the number of lanes closed or with restricted flow and the operating times of the construction when known. This information can be presented to the user through an icon on a map display, a list of construction events, or a modified road color to indicate construction. The detailed information may be presented as a pop-up display or drill-down from a list menu. The information may also be used by a routing engine to modify estimated travel times or suggest alternative routes.
A single service element carries all the construction data, both current (active) and future (planned). The short-term impact of construction events is contained within the predictive and forecast S/F data when it affects the transit time (speed) or congestion level (flow) at that time. This impact is calculated as part of the service data, the application does not need to process construction events additionally to determine their impact.
Incident
The incident service element provides information about non-construction events across the whole of the country. The service contains information about accidents, lane blockages, and special events that affect the flow of traffic in that area. The information can be presented to the user through an icon on a map with additional information available through pop-up or drill-down menus. The information may also be used to make short-term routing changes, particularly for severe accidents that have closed part of a roadway.
Since the duration of accident-type incidents cannot easily be predicted, only current incidents are reported by the service. When an estimate of duration is given, that information may be used to modify the predicted S/F data.
Implementation Options
Not all service elements need to be implemented. The following levels of implementation may serve as a guide when considering what makes the best Apogee service for a given vehicle platform:
Even without a subscription for Apogee traffic, the receiver is still able to receive and process Free-to-Air baseline updates using RFD. Applications are encouraged to support these updates wherever possible, to give the best customer experience when a valid subscription is started
Service Packages (Normative)
The following defines the authentication, addressing and decoding aspects of the Apogee traffic service that are required in order to access and process the service elements described above.
DSI Allocation
The Apogee traffic service may be split between two DSIs. Both DSIs are enabled as part of the Apogee TravelLink subscription. It is still possible to receive and process table updates when the rest of the service is unsubscribed, since the DMIs providing table updates are carried on a Free-To-Air channel.
Subscription Status Reporting
When determining and reporting the overall subscription status of the Apogee service, the application must consider the subscription status of each of the two service DSIs as shown in Table 3: Subscription Status.
DMI Allocation
There are three main blocks of DMIs used to carry the Apogee traffic service. Each block contains 32 DMIs and there is a fixed relation between the offset from the base DMI and a traffic table, as described in section 4. The fourth block of DMIs is used to carry baseline update information using the RFD protocol. The mapping between offset and traffic table is given in section 4.
The mapping between the DSI monitor response and the block values is given in Table 4 above.
Carousels
Within the DMIs a carousel identifier indicates the type of content within the Access Unit. The type of data contained within each carousel is listed in Table 5.
The format of Carousels 6 and 7 are fixed by the RFD protocol.
Service Rates and Sizes (Informative)
The Apogee traffic service does not define the minimum and maximum service rates (the rate at which a particular carousel or DMI will repeat or be rebroadcast) for the various service elements. However, the target update rates given in Table 6 may be used when estimating resource requirements.
The RFD value indicates that a receiver may expect to collect a complete update file after approximately 30 days with the receiver being powered on for 40 minutes each day. The 40 minute value is derived from the typical drive commute times (20-25 minutes each way) reported by the U.S Census Bureau.
Table 7 may be used as a guide when estimating the sizes of the data carousels being transmitted using the service. The division into BSAs is described in section 4, and map filtering is described in section 5.
When estimating storage requirements, these values must be multiplied by the number of TMC tables, BSAs, data types and patterns used by the various service elements being implemented by a particular product or application.
The values in Table 7 represent the maximum size of any single BSA. The aggregate size over a collection area is usually much less than the number of BSA multiplied by the values above. The following factors may help in determining the size of any individual data structure.
For a ‘reasonable’ collection area comprising a rectangle extending 60 miles (100 km) to either side of the vehicle the follows limits apply wherever the rectangle is placed in the continental US.
The ‘all covered BSAs’ linear count is the number of linears within all the BSAs required to cover the map area, including those that lie outside the map. The ‘filtered’ values are the counts after applying the map area filter. These are exact limits based on the 4Q2012 TMC consortium tables and the current Apogee Traffic coverage.
Implementations should plan for up to 6,000 Flow Vectors within a 120 mile square. The application is not required to reserve storage for all 6,000 potential Flow Vectors, it may choose to extract and process them individually, or it may extract them all at once.
Decoding Location Elements
This section describes how the geospatial location elements are contained within the Apogee Traffic Protocol. The general approach is to follow the TISA Traffic Management Channel structure and to base almost all of the geospatial references on their published tables and the ISO-14819-3 international standard [8] and the Location Coding Handbook [9].
Traffic Tables
Apogee Traffic data covers the United States of America and most of the Canadian Provinces. The whole of North America is divided up into a number of traffic tables by the North American TMC Alliance as shown in
The initial Apogee service will cover at least 28 of the 36 tables shown above. Each table is a transmitted as an independent unit for each service element, so an application need only receive and process data for those tables in its immediate vicinity. In some cases, more than one table may be required to completely cover an area, for example between Washington and Philadelphia on the East Coast. In no case does a 100 mile map extent require more than five tables for complete coverage.
Each table shown in
The use of some of these columns is further described below.
Broadcast Service Areas
Within each traffic table, the geographic region is further divided into Broadcast Service Areas (BSAs). This division arose from the terrestrial radio origins of the traffic service. Each BSA is a small number of counties that might be covered by a single traditional radio transmission service.
The term ‘market’ sometimes appears in traffic literature. However, the word has two quite distinct meanings. In some cases a ‘market’ means a whole traffic table, on other cases the word ‘market’ is used to mean a single city or a group of BSAs. To avoid confusion the term ‘market’ is not used within the Apogee Traffic specification.
Within each Broadcast Service Area there are a number of roads. Each road is defined as a linear sequence of TMC points. A TMC point is usually at the intersection of two roads (one point on each roadway) or close to an exit off a freeway or other controlled-access roads. Each point has a longitude and latitude and so can be plotted on a map. The road itself runs between the set of points in the linear.
Lanes
Major highways usually comprise more than one lane in each direction. Where available the Apogee speed and flow service will report individual values for the different classes of lanes on each roadbed.
Ramps
Entrance and exit ramps, shown in green on
Segments and Direction
The Apogee Protocol defines a segment as the stretch of roadway between two adjacent location points in the TMC table. The points are usually defined to be intersections with other roadways or ramps, so the segments may often be many miles long. For each point within a linear, the TMC table defines the next point in the ‘positive’ direction and the next point in the ‘negative’ direction. Endpoints have next points in only one direction.
The direction of travel is determined solely by the POSITIVE and NEGATIVE entries in the TMC table, not by the actual point values (i.e. there is no requirement that POSITIVE means North etc.).
The points are listed in numerical order within the SXM-supplied TMC file, and the examples above demonstrate possible ordering of the points within the file. It is not possible to assume that the first entry for a linear represents the start of the linear, or that the last entry is the end of the linear, the endpoints are only determined by the blank values in the POSITIVE and NEGATIVE columns of the TMC table.
Segments and Map Links
Although the TMC tables use point values to mark locations, in reality these locations extend over some portion of the roadway, particularly when the location contains a high-speed intersection, with ramps. Each of the major map vendors further defines the precise location of the start and end of each segment, in each direction, by referencing their own internal map database, where multiple map links are used to represent a single segment. The following diagrams use map links from the Navteq/Nokia map database, but other vendors' maps will be similar.
The positive direction indicates that the traffic queue is building up towards the next point in the positive direction. Since queues build up at the end, the queue direction is the opposite of the travel direction.
If there was congestion (or an accident) in the southbound lane of 1-75 above at the Jodec Road exit (TMC-4098), then the traffic would start to back up towards TMC-4099. When it reached the point at TMC-4099, this would be represented in Alert-C by a message located at TMC-4098, with an extent of 1, extending in the positive direction. In Apogee this would also be represented as part of the positive Flow Vector.
In order to color the positive Flow Vector, these points must be converted to map database links, on the correct side of the road.
As shown in
Finally, as shown in
Sub-Segments
In exemplary embodiments according to the present invention, a traffic service divides each segment into eight sub-segments, as shown in
Sub-segmenting a linear allows incidents to be accurately positioned along the roadway, and gives much better accuracy of speed and flow data, which translates into improved journey time calculations and better re-routing choices.
The choice of a fixed number (8) of sub-segments is a balance between increased accuracy and processing requirements, both during map preparation and within the vehicle application. The average TMC segment is under 2 miles long, which gives ¼-mile resolution. The resolution represents 15 seconds of travel time at 60 mph and 30 seconds of travel time at 30 mph. These numbers are generally faster than the latency of the speed-and-flow calculation and distribution times, and there is little to be gained, other than a false sense of accuracy, by presenting data with greater precision.
Almost all TMC segments are less than 4 miles long, and ⅛ of this gives half-mile resolution. Very long segments, for example the roads through the Everglades in Florida, have much longer sub-segment lengths. Even in this case the ability to locate an incident along an 8-mile sub-segment is far superior to placing it at the starting point.
Variable-length coding, as used in TPEG, has the advantage of arbitrary precision, but places a large processing burden on the vehicle application, since the application must dynamically calculate the position according to its internal map database. Length-based coding (e.g. 1 mile past TMC point 4100) is not independent of the choice of map database, unlike the SXM approach of division into fixed fractions.
Using a fixed number of sub-segments allows the sub-segment offset to be presented in a known, fixed, number of bits (3 in this case) unlike, say a 0.1 mile distance offset. This simplifies the decoding in the receiver, and also implicitly limits the number of different messages that can be associated with a single segment, providing a much simpler interface between the protocol decoder and the application.
Applications that are already capable of converting distance-based offsets for display can easily convert ⅛-segment positions to their internal format then use their existing system to render the result on the display.
Sub-segment offsets also follow the direction of travel and are presented in units of ⅛-segment.
The purple line in
The brown line represents a stretch of roadway starting ⅞ of the way between 4102 and 4101 and extending % way to 4100, in the ‘negative’ direction of queue-growth. This line would be coded as:
The offset value is relative to the direction of travel, so 4101+⅛ is not the same point as 4101-⅛, as well as being on opposite sides of the road.
The Apogee traffic service reports the speed and flow state separately for each direction in the linear, first for the positive direction and then for the negative direction.
Ramps, which are generally much shorter than segments, do not have sub-segment codes.
Links
Even though a TMC segment is defined as the path between two TMC points, the actual roadbed is unlikely to be a straight line between those two points. In order to draw the roadbed, indicate congestion, and place incident markers, the TMC segment must be converted to a set of map links. A map link is a straight-line drawn between two points, at sufficient resolution that the map follows the actual road topology for a map at a given zoom level.
Links are supplied from a map database, which must be purchased from a map vendor. SiriusXM does not require a specific map-link database, nor does it require the map be obtained from a particular vendor. The Apogee protocol is vendor- and database-agnostic. It is the responsibility of the application developer to obtain both a map database and the TMC consortium traffic tables and to integrate them into their product.
Data Filtering and Data Volume Reduction
There are two reasons to consider a data filtering strategy when implementing the Apogee traffic service:
Recognizing these needs, SiriusXM provides support in both the baseline database files and in the transmission protocol to allow an efficient implementation of the service within the application in the head unit. There are two levels of filtering:
If the vehicle map display is centered around Detroit (the blue rectangle in
Calculating the intersection of two rectangles is a quick and easy operation requiring only comparisons between values (no square roots or trigonometric functions) and can be implemented using fixed-point integer arithmetic. The Bounding Boxes allow the application to skip over areas that lie completely outside the Map Area.
The MBR for an area is calculated as the smallest possible area that could be covered by the contained data considering all the points that lie within it. An MBR is defined by two points, the longitude and latitude of the bottom-left corner, and the longitude and latitude of the upper-right corner, in a geographic projection (i.e. lines of longitude and latitude are a right angles to each other).
As well as MBRs at the table level, Apogee also supports MBRs at the BSA level, and the individual linear level. Using the example in
Even within a BSA, not all linears may lie within the map window, and can be skipped when extracting and processing the data. This leads to the overall structure shown in
MBR filtering is, of course, optional, and an application may choose to process all the linears in a table or BSA even if they are not all destined for the display at that time.
Although each transmission unit contains data for a whole table, the data are divided internally by BSA as shown in
SXM Additional Table Data
SiriusXM supplies a separate ‘locations’ file to accompany each TMC table supplied by the TMC consortium. This file is a Microsoft Excel spreadsheet that defines the index order of the BSA and linears. It supplies the additional information used to implement the spatial filtering methods used to reduce the processing time in the application. The first row of the table contains column headers for the remaining rows as defined in Table 11.
The data records within this file have been re-ordered with respect to the TMC table to create a hierarchical structure of elements that allows filtering by individual BSA and linear. Not all rows have data for all of these columns. The following sections describe how the columns are populated and used.
Service Filtering
Service Elements are grouped into blocks of DMIs by service type, so that a receiver need only monitor the DMIs for the services it is implementing. The DataServiceFilterCmd operation within SXi will restrict the DMIs that are passed from the module to the application for any given DSI. The block structure is shown in Table 4 above. If a receiver is only processing and displaying real-time information around a vehicle it need only select the appropriate tables from DMI blocks A and B and it will never see the Predictive flow information from block C, those data will never leave the module.
Table Filtering
All Apogee data are structured around the TMC table definitions and their geographic extents. Within each block of DMIs, data for a particular TMC table will always be sent on the same DMI, and no other. This allows the receiver to monitor only the DMIs for tables that it needs. To assist in determining the required coverage, fields in the SXM locations file the table-definition record contain the geographic bounding rectangle of the table coverage.
Table 12 describes the additional information available at the table level. If the map display does not intersect the table bounding rectangle, the application is not required to accept and process the data for that table.
Table 13 shows the mapping between the TMC traffic table numbers and the DMIs on which the data for those tables are transmitted. In some cases more than one table is carried on a single DMI. These are low-volume areas where the overhead of receiving multiple tables is not significant.
Three DMIs, 640, 672 and 704 are currently reserved for future use. SiriusXM will not change the assigned DMIs for the lifetime of Protocol Version 1. SiriusXM may add additional tables to existing DMIs, therefore the receiver must check the table identifier inside the protocol header to verify it is processing the correct table.
BSA Indexing
As
Adding the standard FIPS identification code to the county definitions allows a receiver without GPS support to select the appropriate BSA for display based on a user-selectable list of counties in a State.
Linear Indexing
There are three types of linears defined by the TMC tables:
In the standard TMC tables, even normal linears will cross BSA boundaries, as shown in
The TMC definition of this example would be as shown in Table 15.
In order to maintain the standard table structure, this definition is retained in the Apogee version of the table, so that each point exists in only one BSA. However, the Apogee table also includes the bounding rectangle for the linear, which includes all segments that cross the linear boundary, and the full range of points needed to cover the BSA. In the example above, points p1 and p5 are considered to be within BSA B2 when calculating the MBR for that BSA B2. This ensures that the segments crossing the BSA boundary will be included when the list of BSAs is built from the current map rectangle.
This representation leads to the table structure shown in Table 17.
The MBR and range values are contained in the extended SXM field within the TMC table as shown in Table 18.
There are no SXM-defined extensions for the Point values within the TMC table.
Flow Vectors
In the Alert-C protocol, each ‘message’ (5 or 10 byte quantity) is an isolated unit that can be decoded independently of the messages preceding or following it. This has obvious advantages in the noisy or lossy radio environment for which RDS-TMC was developed. For the much more reliable SXM broadcast system this model places unnecessary burdens on the decoding application, mainly:
These concerns are addressed to some extent in the TPEG protocol by the introduction of a Flow Vector, which is essentially the set of speed and flow values along a particular linear arranged so that the messages are in the correct order (following the positive or negative table pointers). The intermediate TMC locations can then be removed since they can be inferred from the position in the flow vector.
The SXM transmission protocol takes the TPEG model one step further. Since the locations file defines the order of the linears within a BSA, the starting point of each speed and flow segment is defined by its index position in the broadcast carousel, and no TMC locations are required in the broadcast.
The following paragraphs describe how Flow Vectors are used within the Apogee traffic service. For the purposes of this introduction, three simplifications have been made:
Again, for illustration, Table 19 uses the color values rather than the congestion codes. This gives the simple structure derived directly from the last column of Table 19 that is used in both the broadcast bitstream and in the pattern tables described in section 7.3.
Ramp Tables
Ramps between Controlled-Access highways are encoded in the TMC traffic tables, as a pair of rows, an L7.0 linear and a single P4.0 point. All the TMC-defined ramps are collected together at the end of the BSA table.
SiriusXM also defines additional ramps, in a table that accompanies each standard TMC Table. The ramps file is a Microsoft Excel spreadsheet that defines the additional ramp locations and types for those ramps not covered by TMC locations. The first row of the table contains column headers for the remaining rows as defined in Table 20.
The two types of ramps (within TMC and SXM additions) are indexed separately, so that additions can be made to either table without requiring changes to the other table. The SXM-defined ramp tables will be updated over the air, as new ramps are added to the service. The TMC-based ramp tables will follow the publication schedule of the consortium and will only be incorporated into new vehicles.
Displaying the Data
This section discusses options for displaying Apogee traffic data.
Speed and Flow Data
The conventional Alert-C coding uses a single message to indicate both congestion and an expected transit speed (e.g. “Congestion: 35 mph”) as well as a simple “Traffic Flowing Freely” message. Without knowledge of the road speed limits it is difficult to gauge if 35 mph represents heavy congestion (on a 75 mph interstate) or light congestion (on a 45 mph arterial). The Apogee speed and flow service separates these two concepts and provides both a congestion indicator and an expected transit speed indicator. This also allows for greater precision in transit times than is supported by the Alert-C event codes.
The usual means of displaying congestion data is by colored lines adjacent to the roadway on a graphical map display. Table 21 gives two sets of suggested colorings, one for displays that can use multiple shades to indicate congestion, and one for displays that with to limit the palette to only three colors.
The congestion lines should follow the path of the roadbed as defined on the underlying map, not simply appear as straight lines between the points as defined in the TMC tables.
Congestion levels for ramps are more broadly defined. Table 22 shows the suggested colors for indicating ramp congestion.
Map Zoom Levels
The Apogee traffic service transmits a large amount of information, more than can reasonably be presented on a small display covering a large geographic area. It is expected that applications would limit the amount of information shown according to the zoom level of the map. There are two main strategies that can be combined to improve information presentation:
For example a long-range trip-planner might show only the free-flow and congestion ‘hot-spots’ along the main interstates to facilitate a broad route selection (i.e. “North then West vs West then North”). Zooming the map in might show the congestion levels of the feeder roads used to access the interstates and so on. Table 23 gives a suggested set of information to display for an application supporting multiple map zoom levels, from multi-state coverage (level 1) down to a few miles in each direction (level 4).
Ramp data display may be determined by zoom level, or ramp data may be displayed once a route has been determined for only those ramps on the route, even at the multi-state coverage.
BSA Patterns
All broadcast speed and flow data are encoded as a difference from a ‘pattern’ which is a pre-defined or previously-transmitted set of speed and flow data for a single BSA that can be used to color all the supported roadways and ramps within that BSA.
There is an implicit NULL pattern which is “No coverage within this BSA” (i.e. do not draw anything). This is the pattern that should be used when no other pattern can be found for a BSA. For example if there are no supported roadways within BSA 19 in a particular table, no data will be transmitted for BSA 19 in the broadcast stream and the application should not color any roadways for that BSA when displaying data on the map.
Delta Codes
Real-time speed and flow data are always coded against the NULL pattern described above. For the first predictive dataset, the pattern is the most recently-received real-time speed and flow pattern. The second predictive dataset is delta-coded from the first, and so on. All forecast and historical patterns are delta-coded from the NULL pattern.
The definition of the delta coding is one of the following operations:
The specific values are coded as absolute values, and so are independent of the value being replaced. This means that for predictive datasets, the actual pattern used as the base pattern is not critical, the outcome of applying the predictive dataset will always be a closer approximation to the prediction that whatever is being used as the current speed and flow dataset.
The default for any segment not explicitly addressed is option ‘a’, leave it unchanged.
Extents
For each direction along a linear, the transit speed and congestion level values are run-length encoded in the Apogee broadcast. This is similar to the Alert-C ‘extent’ coding format but with some simplifications:
Because Apogee traffic has greater resolution than existing Alert-C encodings, the standard rules for Alert-C do not apply. In particular there may be more than one speed/flow state associated with a single TMC segment, and an extent may start and stop in the middle of a TMC segment.
Incident Data
This section describes how construction, accident, and other incident data should be displayed.
Displaying Incident and Construction Data
There are two aspects to the display of incident and construction data. The first is an indication of the presence of an event, the second is informing the user of the nature of the event. Apogee uses the event codes from [8] to indicate the nature of an event. It does not use the ‘event class’ system to limit the number of events at any one location. Multiple events at the same location are permitted in the Apogee traffic system.
Indicating the existence of an event is usually done by placing an icon on the map such as a triangle with a red or yellow border and a graphic to suggest the nature of the event. Selecting the icon, or requesting an event display, should display more information, either a summary with details on a separate screen, or display all the information on the screen at the same time.
When the map shows a large area of the country, icons should be aggregated, or merged, to avoid clutter on the screen. A generic ‘Accident’ icon could represent the 5-10 events in that area which are then listed when the icon is selected. Other options to reduce clutter include suppressing minor events and limiting the display to events on or near a selected route.
Some incident data will have extent information: highlighting the congestion queue that may result from an accident; indicating the number of sub-segments affected by lane construction; showing the length of road that is closed in a road-closure announcement; or describing the extent of a major accident or other incident. Extent information can be used to augment the standard congestion coloring for that part of the roadway, for example to color a closed road as black or a construction as a yellow/black barberpole when congestion is caused as a result of the construction, as shown in
Applications usually choose to place the icon for road construction at the start of the extent (when the driver will first encounter it), and to place an accident or incident icon at the end of the extent (at the point at which the event is occurring).
The textual display of incident and construction data is built up from three components:
An example of TMC-coded accident in Detroit is shown in Table 24.
The offset value can be incorporated into the textual description by using location phrases such as ‘at’, ‘near’, ‘just past’, ‘past’, ‘just before’ etc.
A non-TMC coded event on a specific roadway is shown in Table 25. By including a map-matchable street address a specific road can be identified, even when it is not explicitly TMC coded.
A non-TMC-coded construction event for an unspecified roadway is shown in Table 26. In this case there is insufficient information to identify specific roads within the mall complex but the event can still be geo-located and the user informed of the nature of the event.
The list of Event Codes that can appear in either a construction message or an incident message is shown in Table 27.
Text String Compression
Textual strings use the ISO-8859 (8-bit Latin) repertoire. Each text string is terminated by a byte containing 0x00 (the NUL value), i.e. following the convention C-language representation.
Individual text strings are gathered together to form a String Table, and references to strings are represented as byte offsets into the string table, starting at offset 0. All the strings that are used within a single TMC table for a particular service element are contained within a single string table (it is not divided by BSA).
Text strings are transmitted in a zip-compressed string table, one for each TMC table. The application must decompress the string table and locate the references within it in order to present the textual information to the user. The overall structure of the String Table and String References is shown in
The string table is compressed for transmission using the ‘flate’ protocol as defined by the ‘zlib’ RFC document (RFC 1950, reference [8]). The compressed data does not represent a file (gzip) or directory of files (zip), so the additional headers defined for these aspects of RFC encodings are not present. The compression uses only the block-compression scheme from RFC 1950 and RFC 1951.
The string table is reconstructed using the following pseudo-code:
The resulting byte array can then be directly indexed from the String Reference protocol elements. A string extends from the reference index position up to the next following NUL character in the array.
Information that Crosses BSA Boundaries
An incident, particularly a large-scale construction event, may cover multiple BSAs along a single highway. Since the application may be filtering at the BSA level, and may not be processing the BSA in which the incident starts, incidents that cross BSA boundaries are reported in each BSA that they impact. In such cases, the BSAs that do not contain the start point contain a back-reference to that start point as part of the event message. This allows the application to recognize extended events and only provide one icon for the event, even for multiple messages.
Including the event in all relevant BSAs simplifies the processing within the application, since the application does not need to scan adjacent BSAs, or tables, to determine if there are any events that impact the BSAs being displayed.
Stored Baseline Files
This section discusses the processing that is required to utilize the SXM-supplied baseline files and the over-the-air updates for those baselines.
TMC Consortium Tables
The Consortium and SXM-supplied TMC traffic tables usually require processing before they are usable in a vehicle display system. The individual point locations need to be referenced against the internal map database used by the display. The correlation must be done for both the positive and the negative directions, since for some widely-divided highways, separate map vectors may be used for the two directions.
In many cases there will be more than one map vector between two TMC points (for example when a road curves between the two points). All the map vector components must be considered when calculating the offset points (⅛-segment points). Any coloring of the roads to indicate congestion must follow the map vectors, not assume a single line between the TMC points.
A system that supports multiple map scales (zoom levels) may also need to calculate which of the linears are to be displayed at each zoom level.
The system may also wish to extract the MBR values for the Tables, BSAs and Linears from the SXM-supplied locations table to provide a rapid method for determining which tables and BSAs are required for any given map extent. A system that does not use a GPS sensor to detect position may also wish to extract the county values for each BSA to allow a user to select a location based on State and City or County menus.
Handling Location Table Updates
SiriusXM realizes that there is significant cost and complexity associated with updating in-vehicle navigation and map database systems. The Apogee location referencing model has been designed to work across all future versions of the TMC location tables, as they are released.
Legacy Alert-C coding can cause gaps or overruns in speed-and-flow data, or missed incidents on existing highways, when a TMC point is used that is not in the version of the TMC location table that is built in to the application, as shown in
A receiver that is built with version ‘A’ of the TMC table will correctly interpret the Alert-C that references Points 1 and 3. If a new version ‘B’ of the TMC table is issued that inserts point 99 (because a new intersection was constructed), then systems that are built against that table will correctly interpret references to points 1 and 99. However, the legacy system, shown as ‘C’ above will color segment 3, using its notion of extents, then be unable to color segments from 4 and 5 because it cannot decode a reference to point 99. Similarly, an incident at point 99 would not appear on its map, even though it has a road at that point.
In the case of North America specifically, the TMC tables are essentially complete for the main highway system as it exists today. There are only three cases where significant point additions are being made:
When a point is added into the middle of a linear (‘99’ above) SiriusXM marks this point as ‘New’ in its Locations.xls file. This instructs the map-matching process to ignore that point when calculating the positions of the ⅛-sub-segment boundaries along the linear. SXM will continue to transmit speed-and-flow data for the linear according to the original table definition. Since it is likely that a new intersection changes the pattern at the new location, there is likely to be a break in the flow pattern at that point. This is simply reflected in a change in the sub-segment coloring at that point.
On older units this will appear as a color change in the middle of a segment. On newer units that render the added intersection, the color change will appear close to the added point. In all cases the remaining segments will be colored correctly, irrespective of the underlying TMC table version.
For new construction that results in the extension of a current linear, or the creation of a new linear in the TMC location tables, SXM will create a new linear index at the end of its table for that BSA, even if this is extending an existing indexed linear. These points do not have the ‘New’ flag set and so will be included in the ⅛-segment calculations when the TMC table is integrated into the map database. There will always be an extent break at the junction of the old and new parts of the roadway. Newer systems that have integrated the added points into their map database (and the corresponding SXM Locations.xls file) will be able to display the extension, while older units will ignore it. In both cases the speed-and-flow coverage is consistent with the underlying map as displayed to the user.
Incidents on existing highways will use the original location and offset (like speed-and-flow). Incidents on newly-constructed highways will appear only on new systems. This prevents users from seeing an ‘Overturned Vehicle’ icon in the middle of what is still a field on their maps. Vital incident information can always be carried using the explicit lon/lat format if it is essential to convey that information to all vehicles irrespective of their map status.
If a new intersection results in new ramp TMC codes being allocated, these will be carried at the end of the current ramp table for the BSA. Since they lie beyond the table extent being decoded by older receivers, they will not be displayed.
SXM Ramp Location Tables
Ramp Tables must be correlated against the underlying map database used for the vehicle system display. For TMC-coded points, the point value must be reconciled against a location of a ramp vector in the map database. For SXM-coded points, the TMC location and ramp topology type must be used to select the appropriate ramp vector. Ramps are unidirectional, there are no ‘positive’ and ‘negative’ flow directions, so only one flow value is supplied for a ramp.
New ramps will always be added to the end of the ramp table for a particular BSA. These ramps may use added TMC codes (for example a ramp associated with location ‘99’ added by new construction). Since these codes are always associated with a specific TMC table version, only applications that have integrated that TMC location table will process and display these ramps.
BSA Speed and Flow Patterns
A pattern is a stored set of speed and flow data for a single BSA. There can be up to 256 stored patterns for each BSA. Each baseline pattern file (one for each BSA in the table) contains a set of pattern definitions, in ASCII text. The format of the file is shown in
Each file contains up to 256 pattern entries. Each pattern entry starts with the line:
Each lane-group starts with the line:
Broadcast Code: as defined in Table 37.
Bucket: Speed bucket as defined in Table 38.
Clevel: Congestion level as defined in Table 39.
Extent: as defined in section 9.3.5.
The ramp data section (if_present) starts with the line:
This is followed by lines containing the ramp state information for that pattern, as define in Table 43. The ramp data continue until the next .ramp or .index line, or the end of the file.
Historical Pattern Maps
In exemplary embodiments of the present invention, there can be a single history file for the whole of the Apogee service. Each individual entry can, for example, contain a list of 1344 index values, each in the range 0-255, which comprise the values for the history pattern table for that BSA. Each index value refers to one of the stored pattern values and so provides a way to color that BSA with speed and flow data.
An exemplary file format can be as follows:
In this exemplary format, each BSA starts with a .bsa line followed by 3 integers: the first integer is the table number (1 in the example above); the second integer is the BSA index number (0 in the example above); and the third integer is the number of distinct pattern values in this BSA (20 above).
Each BSA section can, for example, be divided into two blocks, by the lines .summer and .winter, for the summer and winter pattern sets, respectively.
The times used in the index value are always UTC.
The application must determine the appropriate UTC time from the timezone, and Daylight-Savings-Time setting. Even if the particular location does not participate in observing DST, the correct pattern (‘Winter’ or ‘Summer’) must still be used. This is because the congestion pattern at local time 5 pm is maintained as the time zone moves to and from daylight savings time. The application is responsible for determining the correct day of the week, and if that day is a Public Holiday for each of the TMC tables in a map display.
Distribution Format
The S×M baselines may be distributed as a single ZIP archive named Apogee_vxxx.zip where xxx is the version number of the baseline fileset. The archive contains the following directory structure:
The S×M baselines are distributed as a single ZIP archive named Apogee_vxxx.zip where xxx is the version number of the baseline fileset. The archive contains the following directory structure:
There may thus be one directory for each TMC table (TableN). Within that directory is one file containing the SXM additions to the TMC location tables (Locations.xls); one file containing the SXM-defined ramp locations (Ramps.xls). There is one file for each BSA in that table for the M BSAs in that table, containing all the baseline patterns for that BSA (BSAM_patterns.txt). A single file in the top-level directory contains the mapping of time-slots to pattern indexes (History.txt).
Stored File Updates
Two sets of database files are updated over the air, SXM ramp tables and History+Pattern files.
File Selection and RFD Processing
Update files may be transmitted using the SiriusXM Reliable File Delivery (RFD) Protocol, for example, or, in other embodiments, by any file transfer system that allows a large file (up to 4 MByte) to be received as a series of smaller blocks (usually 4 kBytes each) over multiple engine-on cycles and reassembled in the receiver. The RFD distribution protocol, for example, comprises two types of channel, the metadata channel and one or more block data channels.
The metadata channel is carried on the first DMI in block D of Table 4. It contains a list of all the files being transmitted for the service, with their filenames, file identifiers, and the DMI on which the data channel is carried. The file name determines the type of contents (e.g. Ramp Table Update) and the version number of the update. The general approach to handling update files follows these 10 steps:
Once the application is up to date, it need only monitor the RFD metadata channel and does not need to receive or process any of the data packets.
Ramp Table Updates
Only SXM-defined ramps are updated in the ramp tables, not ramps defined by TMC locations. All ramp updates extend the existing tables, so ramp index values are never re-used. This means that a receiver that does not process ramp updates will always see consistent data for its version of the ramp table, but may see data for ramp values beyond the end of the stored table.
Given a ramp table at version V with K+L+M entries, an update to version V+1 will append a further N entries, giving a total of K+L+M+N entries after the update is applied, as shown in
As entries are added to the file, the entries must be correlated with the underlying map database as described in section 7.2.
History and Pattern File Updates
The history and pattern file update changes both the pattern dataset and the history map at the same time. Because the update file may be large, and may take some time to apply, SXM has structured the update file into a sequence of ‘micro-updates’. Each micro-update can be applied in a short period of time, and the contents of the history and pattern tables are always consistent at the end of each micro-update.
Micro-Update Strategy
Each individual pattern update has three micro-updates:
Using this method, the update can be applied incrementally, one micro-update at a time, over multiple engine-on cycles, with no risk of corruption or inconsistent data. Also, the application can continue to use the pattern data during the update. The history service is not locked-out from the application during the update.
Step 1. Isolate
The isolation step removes all references to pattern index 14 from the history map.
After this step, the history table contains the values shown in
Step 2. Update
After step 1 has completed, nothing references pattern 14 any more so the application can now update the pattern dataset with the new pattern 14 at version 3. During this step, the application can still ask for the history pattern for slots 2 or 4, and it will be given pattern 16.
The result of applying step 2 is shown in
Step 3. Use
Once the new pattern 14 has been successfully written into the pattern file, it can be used by the history table. The final step of the update for pattern 14 is to use it again for slot 2:
At this point the update for Table8-BSA6-Pattern 14 is complete and the state is shown in
Updates Over Multiple Engine-on Cycles
The update protocol has been designed so that the process can be interrupted at any point, even in the middle of a micro-update, as long as the application keeps a record of the last successful micro-update that it applied. Each step writes a new value into a history or pattern slot, without needing to know the value that it is replacing, so it is always safe to restart a micro-update at the beginning. However, the individual steps must be applied in the correct order to ensure consistent data.
The Update File
Each pattern update file contains a set of updates for the base patterns and history tables that will bring a receiver from version N−1 to version N of the tables. The name of the update file is Pxxx (e.g. P004) meaning an update from version 3 to version 4.
The update mechanism relies on the system being able to select a ‘good’ backup pattern, which requires that the system is in a known state when the update is applied. For this reason, the application is required to process aj. updates in order (i.e. P001, P002 and P003 must be applied before P004 is applied).
If the receiver is not already at version 3 it must first get the P003 file and apply that before trying to apply P004. Each pattern file is delivered using RFD, and there may be multiple version of the update file (e.g. P001, P002 P003 and P004) being sent at the same time. The application should use the RFD metadata information (which includes the file name) to decide which, if any, of the updates it needs to collect and process. If an application requires more than one file, it may collect all the files in parallel (multiple RFD decodes) or collect and apply them one at a time, depending on receiver resources.
Implementation Strategy
The following exemplary pseudo-code provides a strategy for implementing the update process once the correct update file has been received and re-assembled from the RFD data stream.
This assumes that update_pattern and state are saved to permanent storage whenever they are changed (or as part of the engine-shutdown save-to-disk operations). As long as each step can be completed within an engine-on cycle, this process will terminate, and at all points the data saved to disk will be consistent and usable, as long as operations like ‘replace file’ are atomic in the filing system. Because the steps are each individually self-consistent, it does not matter (other than disk wear) how many times each step is executed.
Decoding SDTP and Access Units
This part of the document defines the protocol encoding used to transmit the Apogee traffic service elements and describes the process of extracting information elements from the encoded data.
The bitstream protocol is defined below by a set of Protocol Tables giving the structure of the bitstream and how to decode it. A generic protocol table usually has 4 columns, as shown in Table 29.
Item 3 repeats COUNT+1 times.
Protocol Table entries are transmitted in the order defined by the Item field in the Protocol Tables. The second column of the Item field is used to indicate repeating elements. The item number also indicates the section or sub-section following in which that item is defined. The label field may appear as a cross-reference between items when a value is used later. In the example above, the four-bit SIZE field determines the number of bits used to decode the VALUE field. A value of ‘0011’ in the SIZE field means 4 bits (3+1) are used for the value. The comment below the table explains how to determine the number of times VALUE appears in the bitstream.
Some fields defined in this specification may not always be present in the bitstream. The presence of such a field is indicated by a single-bit Presence Flag, immediately before the field's place in the bitstream. When set to ‘1’ the Presence Flag indicates that the subsequent field is present. When set to ‘0’, the field is not present.
The use of the Presence Flag is indicated by an “F+” added to the start of the field label, in the Protocol Tables.
Service payloads are carried over the SDTP protocol according to the Normative requirements of [4]. Within the data stream, data are transmitted most significant bit first. The first protocol bit is the 0x80 bit of the first received byte; the second is the 0x40 bit and so on.
As shown in
Each Access Unit contains a protocol-specific header and a 32-bit cyclic redundancy check value in the last 4 bytes. Multiple Access Units may themselves be joined together to form an Access Unit group. The AU group is the largest protocol unit transmitted by the service and contains sufficient protocol data to allow the application to decode and present information for a single table for any of the service elements (carousels) defined below.
SDTP and DMI Filtering
Each SDTP packet contains the DMI of which its data is a part as part of its header. The mapping between DMIs and Service elements is shown in Table 5 above. Each DMI for which the receiver is authorized can be individually enabled or disabled at the SXi level using the DataSvcFilterCmd operation. This can be done is real time, once the service (DSI) is being monitored. The overall process is:
Steps 3-5 must be repeated at the vehicle moves or the user changes the map zoom level or view. If the application is also performing route calculations and travel-time estimates, more tables may be needed to give full coverage over the calculated routes, but the principle remains the same.
Access Units
The maximum size of any Access Unit is 5,120 bytes.
Protocol Version Number
The Protocol Version Number (PVN) occupies the first 4 bits in the header of each Access Unit. It refers to the Protocol Version in use for a particular Access Unit within a data service, and specifies the format of the payload type in the message that follows (for the fields that follow). This feature allows Sirius XM to add new Access Unit formats to existing data streams (DMIs), where new receivers can parse them, while older ones ignore them.
If the PVN field of an Access Unit is different from the one defined in this document, then the contents of the Access Unit will contain syntax not decodable by a receiver compliant with this specification. Receivers shall process all Access Units to the point where the PVN is located. If the PVN value of the Access Unit is not valid for this specification then the entire Access Unit is discarded.
The last 32 bits of each Access Unit contains a 32-bit CRC value. This allows the receiver to validate the data in the Access Unit. The CRC algorithm is identical to the CRC-32 used in [6]. The CRC shall be calculated using the following polynomial:
A receiver may discard an Access Unit before checking the CRC, for example if the PVN field does not match the specification or if the carousel is not one that is required. However, the CRC value shall be checked before any data in the access unit are acted upon. A receiver shall ignore any AU whose check value does not match the calculated value.
Each Access Unit contains data from only one carousel type.
Multi-AU Service Elements
A service element may require more than 5,120 bytes to contain all the information. In this case the information is transmitted in a group of Access Units. Each Access Unit Group contains three protocol elements which control re-assembly of the information content.
These are optional fields, all three are controlled by the initial F+ bit.
CTSIZE is a four bit field whose value determines the size of the two subsequent fields. [CTSIZE]+1 is the size, in bits, of the AUTOT and AUCT fields. If the Presence Flag for CTSIZE is ‘0’, CTSIZE, AUTOT, and AUCT all are not present, and the Access Unit is the only one required to transmit data for this service element.
Access Unit Total (AUTOT)
AUTOT indicates the number of Access Units used to transmit the Grid Definition data for this service element. The number of Access Units is [AUTOT]+1.
Access Unit Count (AUCT)
AUCT is the sequence number of this Access Unit in the Group of Access Units. AUCT is valid in the range 0 to AUTOT.
AU Group Example
The following table gives an example of an AU group containing 4 AUs, using 2 bits to contain the counters:
CTSIZE of ‘01’ means 2 bits are used for the following 2 fields. The values may be read as ‘0 of 3’, ‘1 of 3’, ‘2 of 3’ and ‘3 of 3’.
When assembling a multi-AU group the receiver shall start with an AU having AUCNT value 0 and continue to assemble contiguous AUs having increment sequence numbers. If an AU for that DMI is discarded for any reason, or an AU is received with the wrong AUCNT sequence number, the whole AU group shall be discarded.
Real-Time Lane Speed and Flow (CARID 0)
Carousel id 0 contains the data for real-time speed and flow.
The overall structure of the carousel is show in Table 32 for an Access Unit covering 2 BSAs. Each AU group starts with an AU header that lists the BSAs covered by that Access Unit. This is followed by data for each BSA in the directory. The per-BSA data comprises a list of lane types covered, then blocks of linear data, one block for each lane type. Padding bits are inserted between the BSA data to align the start of the following BSA data on a byte boundary.
AU Header
Each Access Unit in carousel 0 contains the common header shown in Table 33.
Items 4a and 4b are only present when item 4 is present (F=‘1’). Items 6-8 repeat COUNT+1 times.
PVN
The PVN field always contains the value ‘0001’ to identify this AU as conforming to version 1 of the Apogee Protocol.
CARID
The CARID field always contains the value ‘0000’ to identify this carousel as a real-time speed and flow carousel.
TABLE
The TABLE field contains the number of the corresponding TMC traffic table. Although the different traffic tables are carried on different DMIs, SXM may multiplex multiple low-volume tables on a single DMI. The application must use the TABLE value to determine that this table is one that is in its current list of tables to process. The TABLE field is byte-wide and byte-aligned so that it can easily be inspected when filtering out multiple tables on the same DMI.
F+AUGROUP
As defined in section 8.2.3.
For carousel 0, a multi-group Access Unit will only be used when data for a single BSA will not fit into one Access Unit. When F+AUGROUP is present, the BSADIR will contain only a single entry.
When assembling multi-group AUs, only Access Units containing the same BSA and SIG must be concatenated. The resulting protocol data comprises the header from the first AU and all the bytes between the end of the PAD fields and the start of AU-CRC fields, joined end-to-end to form a single continuous bitstream which is then decoded as described below.
Count of Entries (COUNT)
The COUNT field contains the number of directory entries that follow. There are COUNT+1 following entries.
BSA ID (BID)
The BID field contains the BSA index of this entry in the directory. This is the index value in the order defined by the SXM version of the appropriate TMC traffic table, it is not the TMC reference number for the BSA.
Offset to BSA Data (OFFSET)
The OFFSET field contains the byte offset from the start of the Access Unit group at which the data for this BSA starts.
Change Detection Signature (SIG)
The SIG field contains a signature value computed over the data for this BSA. An application can use this value to decide if the data have changed since the last time the application processed an Access Unit for this BSA. If the signature value differs from the one previously processed, the contents of that BSA has definitely changed. If the value is the same, the contents are probably unchanged (with a 1 in 65,536 chance of missing a real change).
PAD
The PAD field contains from zero to seven bits to bring the header up to a byte boundary.
Lane Data
Each BSA in the AU group starts with an optional Lane Data index. If this BSA contains speed and flow data for more than one lane type the fields in Table 34 are present, otherwise the lane data is encoded as ‘0’ and only data for the main roadbed is present.
Item 2 repeats LANES+1 times,
If lane data are present, the F field is ‘1’ and the LANES field contains the count of LTYPE value following. The number of LTYPEs in this BSA is LANES+1.
LTYPE
The LTYPE field encodes the type of lane in that section of the following speed and flow data using the values in Table 35.
The main roadbed will always be the first entry in the set of lane data linear blocks. The order of the other lane types within that BSA is not defined.
Linear Data
For each BSA in the AU group, the data in Table 36 are repeated once for each lane type defined by the Lane Data index. The data for each lane follows immediately from the data for the previous set of lanes, with no intermediate padding bits.
Items 2-5 repeat for each linear in the BSA for LCOUNT+1 linears. The order in which the linears appear in the bitstream is the same order as they are defined in the SXM locations spreadsheet, as described in section 5.
The following exemplary pseudo-code decodes the linear data for a single lane type within a BSA.
The sequence of ‘01’ and ‘10’ coded values terminates when the code bits are ‘00’ indicating no further changes to that linear.
LCOUNT
The LCOUNT field contains the number of linears for which data are present in the following data group. The number of values following is LCOUNT+1. The first data are for linear 0 in the BSA according to the SXM traffic table index of linears, the next data are for linear 1, and so on. Note that the number of linears in the data block may be different for each lane type.
CODE
Each linear is represented by one or more CODE values with the meanings shown in Table 37.
Code values ‘01’ and ‘10’ are always terminated with an explicit ‘00’ code. This allows the application to skip over a linear without requiring access to the TMC tables to determine the length of the linear.
BUCKET
The BUCKET field encodes the expected transit segment over the linear extent using the values in Table 38.
CLEVEL
The CLEVEL field encodes the perceived congestion level over the linear extent using the values in Table 39.
EXTENT
The EXTENT field encodes the number of sub-segments (⅛ segment) for which the BUCKET and CLEVEL apply. The field is only present when the CODE value is ‘01’ or ‘10’. The actual number of sub-segments covered is EXTENT+1.
PAD
Each complete BSA entry may be followed by 0-7 zero bits to align the bitstream to a byte boundary. Note that this means the application must use the BSA directory information to locate the start of each BSA within the Access Unit, it cannot assume that the bits for one BSA start where the last BSA ended.
Real-Time Ramp Flow (CARID 1)
Carousel id 1 contains the data for real-time flow data for ramps.
Table 40 above shows the overall structure of carousel 1 for a table containing ramp data for 2 BSAs.
AU Header
Each Access Unit in carousel 1 contains a common header defined in Table 41.
PVN
The PVN field always contains the value ‘0001’ to identify this AU as conforming to version 1 of the Apogee Protocol.
CARID
The CARID field always contains the value ‘0001’ to identify this carousel as a real-time ramp flow carousel.
TABLE
The TABLE field contains the number of the corresponding TMC traffic table. Although the different traffic tables are carried on different DMIs, SXM may multiplex multiple low-volume tables on a single DMI. The application must use the TABLE value to determine that this table is one that is in its current list of tables to process. The TABLE field is byte-wide and byte-aligned so that it can easily be inspected when filtering out multiple tables on the same DMI.
F+AUGROUP
As defined in section 8.2.3 and shown in
For carousel 1, a multi-group Access Unit will only be used when data for a single BSA will not fit into one Access Unit. When F+AUGROUP is present, the BSADIR will contain only a single entry. When assembling multi-group AUs, only Access Units containing the same BSA and SIG must be concatenated. The resulting protocol data comprises the header from the first AU and all the bytes between the end of the PAD fields and the start of AU-CRC fields, joined end-to-end to form a single continuous bitstream which is then decoded as described below.
Count of Entries (COUNT)
The COUNT field contains the number of directory entries that follow. There are COUNT+1 following entries. These entries determine how to decode the Ramp Data that follows, the BSA directory for ramp data is complete separate from the directory values used to interpret the speed-and-flow data.
BSA ID (BID)
The BID field contains the BSA index of this entry in the directory. This is the index value in the order defined by the SXM version of the appropriate TMC traffic table, it is not the TMC reference number for the BSA.
Offset to BSA Data (OFFSET)
The OFFSET field contains the byte offset from the start of the Access Unit group at which the data for this BSA starts.
Change Detection Signature (SIG)
The SIG field contains a signature value computed over the data for this BSA. An application can use this value to decide if the data have changed since the last time the application processed an Access Unit for this BSA. If the signature value differs from the one previously processed, the contents of that BSA has definitely changed. If the value is the same, the contents are probably unchanged (with a 1 in 65,536 chance of missing a real change).
PAD
The PAD field contains from zero to seven bits to bring the header up to a byte boundary.
Ramp Data
Each BSA in the Access Unit contains the data defined in Table 42.
Item 3a repeats for COUNT1 entries. This is followed by Item 3b which repeats for COUNT2 entries.
COUNT1
The COUNT1 field contains the number of RLEVEL entries that are indexed by direct TMC code in the main TMC traffic table. If this field is zero, there are no directly-coded TMC entries in this BSA.
COUNT2
The COUNT2 field contains the number of RLEVEL entries that are indexed additional SXM-defined ramp codes. These RLEVEL values follow immediately after the directly-coded TMC ramp values. If this value is zero, there are not SXM-defined ramp entries in this BSA.
RLEVEL
The RLEVEL field contains the congestion level indicator for that ramp, according to the values in Table 43.
PAD
The PAD field contains from 0-7 zero bits to align the BSA data onto a byte boundary.
Construction Data (CARID 2)
Carousel id 2 contains data for construction events.
Table 44 shows the structure of carousel 2 for a table with construction data in 2 BSAs. The construction data are followed by a single block of data containing the zipped string table for the whole of the TMC table.
AU Header
Each Access Unit in carousel 2 contains a common header defined in Table 45.
Items 4a-4c are only present when item 4 is present (F=‘1’).
PVN
The PVN field always contains the value ‘0001’ to identify this AU as conforming to version 1 of the Apogee Protocol.
CARID
The CARID field always contains the value ‘0010’ to identify this carousel as a construction data carousel.
TABLE
The TABLE field contains the number of the corresponding TMC traffic table. Although the different traffic tables are carried on different DMIs, SXM may multiplex multiple low-volume tables on a single DMI. The application must use the TABLE value to determine that this table is one that is in its current list of tables to process. The TABLE field is byte-wide and byte-aligned so that it can easily be inspected when filtering out multiple tables on the same DMI.
F+AUGROUP
As defined in section 8.3.3.
For carousel 2, a multi-group Access Unit will be used whenever the access unit needed to contain the construction data for the whole of a TMC table exceeds 5,120 bytes. The application should concatenate the payload data (following the AU Header) for each Access Unit in the group, and then process the resulting bitstream according to the following protocol. Only Access Units with the same AUID should be joined to form the final group.
PAD
The PAD field contains from 0-7 bits to align the AU Header to a byte boundary.
AU Group Header
Each AU Group starts with an AU group header, immediately following the AU Header of the first AU in the group.
All of the items in the AU Group Header are multiples of 8 bits, so there is no padding required at the end of the Group Header. The length of each BSA entry is the difference between the start of the next entry (or the start of the string table) at the start of the current entry.
STRINGOFF
The STRINGOFF field contains the offset of the first byte of the string table, in bytes from the start of the AU Group Header.
STRINGLEN
The STRINGLEN field contains the number of bytes in the compressed string table.
Count of Entries (COUNT)
The COUNT field contains the number of directory entries that follow. There are COUNT+1 following entries. These entries determine how to decode the Construction Data that follows, the BSA directory for ramp data is complete separate from the directory values used to interpret the speed-and-flow or incident data.
BSA ID (BID)
The BID field contains the BSA index of this entry in the directory. This is the index value in the order defined by the SXM version of the appropriate TMC traffic table, it is not the TMC reference number for the BSA.
Offset to BSA Data (OFFSET)
The OFFSET field contains the byte offset from the start of the Access Unit group at which the data for this BSA starts.
Change Detection Signature (SIG)
The SIG field contains a signature value computed over the data for this BSA. An application can use this value to decide if the data have changed since the last time the application processed an Access Unit for this BSA. If the signature value differs from the one previously processed, the contents of that BSA has definitely changed. If the value is the same, the contents are probably unchanged (with a 1 in 65,536 chance of missing a real change).
Construction Data
Each BSA contains a set of construction data elements defined by Table 46.
Items 7, 7a and 7b repeat while the F+ flag (item 7) is ‘1’.
LOCATION
The LOCATION field determines the format of the primary location reference within this BSA. The first bit of the location field determines the type of the location reference.
Type ‘0’ is a TMC-based reference, type ‘1’ is a lon/lat value.
TMC-Referenced Location
LOCTYPE
The LOCTYPE field contains ‘0’ to identify this as a TMC-based location reference.
TMC
The TMC field contains a TMC Point value in the current table.
OFFSET
The OFFSET field contains a ⅛-subsegment offset from the TMC point.
DIRECTION
The DIRECTION field specifies how the TMC table is traversed to build up a sequence of segments into a linear extent. It is a single bit with the following meaning:
If construction events occur on both sides of the road at the same location, two separate messages will be present in the bitstream, one for each direction.
EXTENT
The EXTENT field defines the extent of the construction, from the starting point, in the specified direction.
F+FULLSTART
If the construction starts outside the current BSA, then the FULLSTART field contains the starting location in another BSA. If the construction starts in this BSA, but extends into another BSA, this field is not present.
TMC
The TMC field contains a TMC Point value in the current table at which the construction starts. This field is only present if FULLSTART is present.
OFFSET
The OFFSET field contains a ⅛-subsegment offset from the TMC point at which the construction starts. The direction of the offset is the same as the DIRECTION field for the main location. This field is only present if FULLSTART is present.
Geographic-Referenced Location
LOCTYPE
The LOCTYPE field contains ‘1’ to identify this as a geographic-based reference.
LONGITUDE
The LONGITUDE field contains a fixed-point integer in the range [−180-0] in 8.17 format. The actual value is:
The LATITUDE field contains a fixed-point integer in the range [0-90] in 7.17 format.
The actual value is:
The LOCATIONTEXT field contains a description of the location (since no TMC location is available). This may be a generic location (“Quakerbridge Mall”) or a specific point not referenced by TMC (“The Rest Area off Rt.1 at Wake Forest”).
EVENT
The EVENT field contains an Alert-C event code from the list in Table 27. The application may wish to use this field to select an appropriate icon for the event on the display.
SEVERITY
The SEVERITY field contains a value to indicate the expected impact of this construction on traffic flow and travel times. The values are defined in Table 50.
The severity code may be used to color the border of an icon, or to suppress lesser-impact events when more severe events must be presented.
F+ID
The optional ID field contains am 8-bit value that identifies a unique event at this location (by TMC or georeference). An application can use this field to determine if two events received in different carousels are for the same underlying physical event. If the field is absent, the ID shall be treated as zero for comparison purposes.
LANG
The LANG field describes the language of the following text field. The values are defined in Table 51
TEXT
The TEXT field contains a byte offset into the string table. The string value contains the text description of the construction to be displayed as the ‘details’ in a list or pop-up display.
F+LANG/TEXT
In the case where the same text message is available in more than one language, the optional F+ fields contain additional language+text values. The list of additional values is terminated with the ‘0’ flag bit.
F+EXT
The optional EXT field contains additional extended data not decodable by this version of the protocol. If the F bit is ‘1’ it is followed by 7 bits of length information. These are the number of 8-bit quantities contained in the extension field. A receiver compliant with the PVN ‘0001’ must skip over these bits and resume parsing at the start of the next construction event:
PAD
The PAD field contains from 0-7 zero bits to align each BSA construction data to a byte boundary.
STRINGS
The STRINGS field contains the compressed String Table for all of the strings used in the Access Unit Group.
Incident Data (CARID 3)
Carousel id 3 contains the data for accident and incident events. The overall structure of the carousel is shown in Table 52.
AU Header
Each Access Unit in carousel 3 contains a common header defined in Table 53.
Items 4a-4c are only present when item 4 is present (F=‘1’).
PVN
The PVN field always contains the value ‘0001’ to identify this AU as conforming to version 1 of the Apogee Protocol.
CARID
The CARID field always contains the value ‘0011’ to identify this carousel as an incident data carousel.
TABLE
The TABLE field contains the number of the corresponding TMC traffic table. Although the different traffic tables are carried on different DMIs, SXM may multiplex multiple low-volume tables on a single DMI. The application must use the TABLE value to determine that this table is one that is in its current list of tables to process. The TABLE field is byte-wide and byte-aligned so that it can easily be inspected when filtering out multiple tables on the same DMI.
F+AUGROUP
As defined in section 8.3.3.
For carousel 3, a multi-group Access Unit will be used whenever the incident data for the whole of a TMC table exceeds 5,120 bytes. The application should concatenate the payload data (following the AU Header) for each Access Unit in the group, and then process the resulting bitstream according to the following protocol. Only Access Units with the same AUID should be joined to form the final group.
PAD
The PAD field contains from 0-7 bits to align the AU Header to a byte boundary.
AU Group Header
Each AU Group starts with an AU group header, immediately following the AU Header of the first AU in the group.
All of the items in the AU Group Header are multiples of 8 bits, so there is no padding required at the end of the Group Header. The length of each BSA entry is the difference between the start of the next entry (or the start of the string table) at the start of the current entry.
STRINGOFF
The STRINGOFF field contains the offset of the first byte of the string table, in bytes from the start of the AU Group Header.
STRINGLEN
The STRINGLEN field contains the number of bytes in the compressed string table.
Count of Entries (COUNT)
The COUNT field contains the number of directory entries that follow. There are COUNT+1 following entries. These entries determine how to decode the Incident Data that follow, the BSA directory for ramp data is complete separate from the directory values used to interpret the speed-and-flow or construction data.
BSA ID (BID)
The BID field contains the BSA index of this entry in the directory. This is the index value in the order defined by the SXM version of the appropriate TMC traffic table, it is not the TMC reference number for the BSA.
Offset to BSA Data (OFFSET)
The OFFSET field contains the byte offset from the start of the Access Unit group at which the data for this BSA starts.
Change Detection Signature (SIG)
The SIG field contains a signature value computed over the data for this BSA. An application can use this value to decide if the data have changed since the last time the application processed an Access Unit for this BSA. If the signature value differs from the one previously processed, the contents of that BSA has definitely changed. If the value is the same, the contents are probably unchanged (with a 1 in 65,536 chance of missing a real change).
Incident Data
Each BSA contains a set of incident data elements defined by Table 55.
Items 7, 7a and 7b repeat while the F+ flag (item 7) is ‘1’.
LOCATION
As defined in section 11.3.1.
EVENT
The EVENT field contains an Alert-C event code. The list of events that are used in the Apogee broadcast for incidents is given in Table 27. The application may wish to use this field to select an appropriate icon for the incident on the display.
SEVERITY
The SEVERITY field contains a value to indicate the expected impact of this incident on traffic flow and travel times. The values are defined in Table 56.
The severity code may be used to color the border of an icon, or to suppress lesser-impact events when more severe events must be presented.
F+ID
The optional ID field contains am 8-bit value that identifies a unique event at this location (by TMC or georeference). An application can use this field to determine if two events received in different carousels are for the same underlying physical event. If the field is absent, the ID shall be treated as zero for comparison purposes.
LANG
The LANG field describes the language of the following text field. The values are defined in Table 51 above
TEXT
The TEXT field contains a byte offset into the string table. The string value contains the text description of the incident to be displayed as the ‘details’ in a list or pop-up display.
F+LANG/TEXT
In the case where the same text message is available in more than one language, the optional F+ fields contain additional language+text values. The list of additional values is terminated with the ‘0’ flag bit.
F+EXT
The optional EXT field contains additional extended data not decodable by this version of the protocol. If the F bit is ‘1’ it is followed by 7 bits of length information. These are the number of 8-bit quantities contained in the extension field. A receiver compliant with the PVN ‘0001’ must skip over these bits and resume parsing at the start of the next construction event:
PAD
The PAD field contains from 0-7 zero bits to align each BSA incident data to a byte boundary.
STRINGS
The STRINGS field contains the compressed String Table for all of the strings used in the Access Unit Group.
Predictive Speed and Flow (CARID 4)
Carousel id 4 contains the data for the short-term predictive speed and flow service. This contains the speed and flow data that extends from the current time to up to 1 hour into the future.
The overall structure of the carousel is show in Table 57 for an Access Unit covering 2 BSAs. Each AU group starts with an AU header that lists the BSAs covered by that Access Unit. This is followed by data for each BSA in the directory. The per-BSA data comprises a list of lane types covered, then blocks of linear data, one block for each lane type. Padding bits are inserted between the BSA data to align the start of the following BSA data on a byte boundary.
AU HEADER
Each Access Unit in carousel 4 contains a common header defined in Table 58.
Item 5a repeats PCOUNT+1.
Items 6a and 6b are only present when item 6 is present (F=‘1’).
PVN
The PVN field always contains the value ‘0001’ to identify this AU as conforming to version 1 of the Apogee Protocol.
CARID
The CARID field always contains the value ‘0100’ to identify this carousel as a real-time speed and flow carousel.
TABLE
The TABLE field contains the number of the corresponding TMC traffic table. Although the different traffic tables are carried on different DMIs, SXM may multiplex multiple low-volume tables on a single DMI. The application must use the TABLE value to determine that this table is one that is in its current list of tables to process. The TABLE field is byte-wide and byte-aligned so that it can easily be inspected when filtering out multiple tables on the same DMI.
SEQUENCE
Each predictive dataset is delta-coded from the previous predictive dataset. The SEQUENCE field indicates from which dataset this one is coded. SEQUENCE=0 means the dataset is delta-coded from the most recent current conditions, SEQUENCE=1 means the dataset is delta-coded from the first predictive dataset, and so on. The start time for that prediction is contained in the OFFSET[SEQUENCE] value
PCOUNT+OFFSET
The PCOUNT field indicates the number of predictive datasets currently being transmitted. This is followed by PCOUNT+1 values giving the OFFSET times for each dataset. The OFFSET field indicates the start of the valid period for the prediction at sequence number SEQUENCE. The value is coded in units of 5 minutes relative to the time at which the carousel was received. The field may be converted into a unixtime by:
unixtime=now+value×300
Predictions are valid for no more than 30 minutes from the start time, or until the start of a later prediction or forecast point.
F+AUGROUP
As defined in section 8.3.3.
For carousel 4, a multi-group Access Unit will only be used when data for a single BSA will not fit into one Access Unit. When F+AUGROUP is present, the BSADIR will contain only a single entry. When assembling multi-group AUs, only Access Units containing the same BSA and SIG must be concatenated. The resulting protocol data comprises the header from the first AU and all the bytes between the end of the PAD fields and the start of AU-CRC fields, joined end-to-end to form a single continuous bitstream which is then decoded as described below.
PAD
The PAD field contains from 0-7 zero bits to bring the header up to a byte boundary.
AU Group Header
Each AU Group starts with an AU group header, immediately following the AU Header of the first AU in the group, as defined in Table 59.
Count of Entries (COUNT)
The COUNT field contains the number of directory entries that follow. There are COUNT+1 following entries. These entries determine how to decode the Speed and Flow Data that follow, the BSA directory for predictive data is complete separate from the directory values used to interpret the real-time speed-and-flow data.
BSA ID (BID)
The BID field contains the BSA index of this entry in the directory. This is the index value in the order defined by the SXM version of the appropriate TMC traffic table, it is not the TMC reference number for the BSA.
Offset to BSA Data (OFFSET)
The OFFSET field contains the byte offset from the start of the Access Unit group at which the data for this BSA starts.
Change Detection Signature (SIG)
The SIG field contains a signature value computed over the data for this BSA. An application can use this value to decide if the data have changed since the last time the application processed an Access Unit for this BSA. If the signature value differs from the one previously processed, the contents of that BSA has definitely changed. If the value is the same, the contents are probably unchanged (with a 1 in 65,536 chance of missing a real change).
Lane Data
As defined in section 9.2
Linear Data
As defined in section 9.3. For predictive data, where the values are being applied against a base pattern, the bucket value 15, as defined in Table 38, may appear, to replace a previously colored sub-segment with ‘no coverage’.
PAD
The PAD field contains from 0-7 bits to align each BSA flow data to a byte boundary.
Forecast Speed and Flow (CARD 5)
Carousel id 5 contains the data for the forecast speed and flow service. This contains the data for speed and flow data for the period from 1 hour from now up to 3-4 hours from now.
The overall structure of the carousel is shown in Table 60 for an Access Unit covering 2 BSAs. Each AU group starts with an AU header that lists the BSAs covered by that Access Unit. This is followed by data for each BSA in the directory. The per-BSA data comprises values identifying the appropriate traffic pattern that forecast period.
AU Header
Each Access Unit in carousel 5 contains a common header defined in Table 61.
For forecast data, the total data volume for a single BSA can never exceed 5,120 bytes, so there are no AUGROUP fields in the AU Header.
PVN
The PVN field always contains the value ‘0001’ to identify this AU as conforming to version 1 of the Apogee Protocol.
CARID
The CARID field always contains the value ‘0101’ to identify this carousel as a forecast carousel.
TABLE
The TABLE field contains the number of the corresponding TMC traffic table. Although the different traffic tables are carried on different DMIs, SXM may multiplex multiple low-volume tables on a single DMI. The application must use the TABLE value to determine that this table is one that is in its current list of tables to process. The TABLE field is byte-wide and byte-aligned so that it can easily be inspected when filtering out multiple tables on the same DMI.
OFFSET
The OFFSET field indicates the start of the valid period for the first forecast in the group. The value is coded in units of 5 minutes relative to the time at which the carousel was received. The field may be converted into a unixtime by:
offset=now+value×300
This value is the base value from which the other forecast points are calculated.
DELTA
The DELTA field gives the time increment between forecasts, in units of 5 minutes, so the second forecast is at:
unixtime=offset+delta×300
and the third at:
The FCOUNT field gives the number of forecasts for each group.
PAD
The PAD field contains from 0-7 zero bits to align the following BSA directory on a byte boundary.
Count of Entries (COUNT)
The COUNT field contains the number of directory entries that follow. There are COUNT+1 following entries. These entries determine how to decode the Forecast Data that follows.
BSA ID (BID)
The BID field contains the BSA index of this entry in the directory. This is the index value in the order defined by the SXM version of the appropriate TMC traffic table, it is not the TMC reference number for the BSA.
Offset to BSA Data (OFFSET)
The OFFSET field contains the byte offset from the start of the Access Unit group at which the data for this BSA starts.
Change Detection Signature (SIG)
The SIG field contains a signature value computed over the data for this BSA. An application can use this value to decide if the data have changed since the last time the application processed an Access Unit for this BSA. If the signature value differs from the one previously processed, the contents of that BSA has definitely changed. If the value is the same, the contents are probably unchanged (with a 1 in 65,536 chance of missing a real change).
Forecast Data
Items 1-3 repeat FCOUNT+1 times.
PATTERN
The PATTERN field contains a reference to a stored pattern to be used as the speed and flow data for that time period.
F+MINVER
The F+MINVER field contains the minimum pattern version that may be used for this forecast. If the stored pattern version is less than this value, the historical pattern shall be used. If the F bit is ‘0’, no minimum-version check shall be performed
F+MAXVER
The F+MAXVER field contains the maximum pattern version that may be used for this forecast. If the stored pattern version exceeds this value, the historical pattern shall be used. If the F bit is ‘0’ no maximum-version check shall be performed.
PAD
The PAD field contains from 0-7 zero bits to align the forecast data to a byte boundary.
RFD-Based File Updates (CARID 6 and CARID 7)
Carousel id 6 is used to transmit the metadata for the update files sent using RFD. Carousel id 7 contains the data blocks. Note that carousel 7 may appear on multiple DMIs.
RFD Metadata (CARID 6)
The format of the Access Units used to carry RFD metadata is defined by the RFD protocol specification. Table 63 refines that definition with the specific values used for Apogee Traffic in the AU header.
PVN
The PVN field always contains the value ‘0001’ to identify this AU as conforming to version 1 of the Apogee Protocol.
CARID
The CARID field always contains the value ‘0110’ to identify this carousel as the RFD metadata carousel.
The remaining fields are defined by the RFD protocol. The Apogee RFD transmission system also uses the first extension field (in the F+EXT field of the metadata packet) to define the DMI on which the data packets are carried.
Carousel Updates for Ramp Tables (CARID 7)
Ramp data updates are always sent in RFD ‘carousel’ mode, to reduce the processing requirements. Each file is named Rxxx where xxx is the version number of the update.
The transmission format comprises a set of Access Units as defined by the RFD data transmission protocol, using carousel id ‘7’. Once the data file has been received and reassembled it can be decoded according to the following specification.
Ramp Update File Header
The file starts with a file header defined in Table 64 which contains an index table for the ramp table updates in the file. The application can use this table as part of a strategy for handling updates that are interrupted by a power or engine-on cycle, by restarting at the most recent incomplete update.
Items 5-7 repeat UCOUNT+1 times.
PVN
The PVN field defines the format of the contents of the Ramp Update File. The format defined below is identified by ‘0001’ in the PVN field.
TYPE
The TYPE field contains ‘0001’ to identify this file as a Ramp Update File.
VERSION
The VERSION field contains the version number of this update. Taken together, the TYPE and VERSION fields identify the function of the file independently from the file name used to transmit the file over RFD, and can be used as a cross-check, or recovery method if the RFD filename is not available. The mapping is Rxxx becomes TYPE=‘1’ VERSION=xxx.
UCOUNT
The UCOUNT field contains the number of update blocks in the file.
TABLE
The TABLE field contains the TMC table number for this update block.
BSA
The BSA field contains the BSA Index number for this update block.
OFFSET
The OFFSET field contains the byte offset from the start of the file at which the File Data for this update block is located.
Ramp Update File Data
Each file data update block contains the items in Table 65.
Items 3 and 4 repeat RCOUNT+1 times.
RCOUNT
The RCOUNT field contains the number of update entries in this block.
INDEX
The index field contains the starting index number for the first update record. All updates are ADD operations to the previous version of the table. If a record is found at that index value, due to an update that did not complete, that record should be deleted and the new one inserted.
TMC
The TMC field contains the TMC point location at which the ramp is anchored.
RTYPE
The RTYPE field contains the ramp topology type, as defined in
MBR
The encoding of the MBR fields (items 5-8) are as define d in section 11.3.1.2.
PAD
The PAD field contains 0-7 bits to align the update block to a byte boundary.
RFD Updates for History and Patterns (CARID 7)
History and pattern update files are sent in ECC1 or ECC2 modes so that the large file may be collected over a period of many days, then reassembled. Each file is named Pxxx where xxx is the version number of the update. The maximum size of any single update file is 4,096 kbytes.
The transmission format comprises a set of Access Units as defined by the RFD data transmission protocol, using carousel id ‘7’. Once the data file has been received and reassembled is it decoded according to the following specification.
History Update File Header
The file starts with a file header defined in Table 66 which contains an index table for all the pattern updates in the file.
Items 5-8 repeat UCOUNT+1 times.
PVN
The PVN field defines the format of the contents of the History and Pattern Update File. The format defined below is identified by ‘0001’ in the PVN field.
TYPE
The TYPE field contains ‘0000’ to identify this file as a History and Pattern Update File.
VERSION
The VERSION field contains the version number of this update. Taken together, the TYPE and VERSION fields identify the function of the file independently from the file name used to transmit the file over RFD, and can be used as a cross-check, or recovery method if the RFD filename is not available. The mapping is Pxxx becomes TYPE=‘0’ VERSION=xxx.
UCOUNT
The UCOUNT field contains the number of update blocks in the file.
TABLE
The TABLE field contains the TMC table number for this update block.
BSA
The BSA field contains the BSA Index number for this update block.
INDEX
The INDEX field contains the pattern index number (0-255) for the pattern being updated.
OFFSET
The OFFSET field contains the byte offset from the start of the file at which the File Data for this update block is located.
History Update File Contents
Items 3a and 4a repeat COUNT1 times, followed by items 3b and 4b which repeat COUNT2 times (note that either or both of COUNT1 and COUNT2 may be zero). Item 8 repeats according to the number of lanes in the lane data.
COUNT1
The COUNT1 field contains the number of pattern SET operations that are to be performed before the pattern update is applied. This field may be zero if no pre-move updates are to be performed. The first COUNT1 entries in items 3a and 4a are the pre-move entries,
COUNT2
The COUNT2 field contains the number of pattern SET operations that are to be performed after the pattern update has been applied. The field may be zero if no post-move updates are to be performed. The last COUNT2 entries in items 3b and 4b are the post-move entries.
INDEX
The INDEX field contains the pattern index value in the history table that is to be updated.
PATTERN
The PATTERN field contains the new pattern index value (0-255) for that history table entry.
PAD
The PAD field contains 0-7 bits to align the move table to a byte boundary.
RAMPOFFSET
The RAMPOFFSET field contains the offset to the start of the Ramp Update portion of the pattern. If this field is zero, there are no ramp values for this pattern.
LANE
The LANE field contains the lane directory for the main roadbed speed-and-flow data, as defined in Table 34.
LINEAR
The LINEAR field contains the linear speed-and-flow pattern data, one set per lane, as defined in Table 36.
RAMPDATA
The RAMPDATA field contains the ramp speed-and-flow pattern data, as defined in Table 42.
Implementation and Integration with SMS
This section considers additional algorithms and suggestions for implementation.
MBR Filtering
MBR filtering can be implemented using only simple comparisons once the map MBR has been established. An MBR can be represented as a C structure with 4 fixed-point values (32-bit integers are adequate for this operation allowing 6 decimal places of accuracy).
Then determining if a point lies within the MBR is simply:
When processing individual segments within a linear, the following test will detect all lines that either cross or come close to the map MBR:
Where sgn is the signum (sign of) function.
The basic bounding-box filter, which selects only those GeoMbrs that may potentially have points within the map MBR is calculated by:
All these tests use simple arithmetic or comparisons, and no trigonometric functions.
Setting the Overall Apogee Filter
The filter is composed from a set of tables and BSA numbers and bit values, one bit per linear, that says if the linear is to be included (‘1’) or excluded (‘0) from processing. It is recomputed only when the application requests a new map coverage area. The process is:
This completes the filter setting. The receiver then subscribes to the set of DMIs required to collect all the data for the tables marked for collection.
Duplicate Detection
Typically Real-Time Speed and Flow data are recalculated every 150-180 seconds, so the same carousel may be transmitted 3 or 4 times before it changes. If the application has already processed one instance of the carousel it does not need to check and decode an identical copy. It can discard an Access Unit as a duplicate if [and only if]:
These checks can all be made on the AU wrapper and header, without requiring that the contents be decoded. If it is determined that the AU has changed, then each BSA can be examined using the signature field in the header (for the BSA-directory encoding method). If the signature has not changed, then that BSA need not be processed again. Because extents never cross BSA boundaries, the state of those linears will be identical even if other BSAs in the Access Unit have different data.
Skipping Linears
When a linear is not required for display it can be skipped over using the following pseudocode:
Unlike the Alert-C encoding, the linear can be skipped over quickly, without requiring any references to external TMC tables or any further calculations.
Processing Linears
Linears that need to be displayed can be processed using the following pseudo-code
Filter Operation
Putting all the pieces together leads to an overall flowchart for efficient processing of Apogee traffic data as shown in
Integration with SMS
The overall structure of an exemplary system that uses SMS to process the Apogee protocol is shown in each of
Another main advantage of SMS is that it can also manage some of the baseline files and over-the-air database updates on behalf of the application, leaving the application to manage the TMC tables and its own map database. Thus, for example,
Part II—Exemplary Architecture
The following section describes an exemplary overall architecture and proposed implementation of the Apogee Traffic Service.
As noted, “Apogee” or “Apogee Traffic” is a name given by Applicants to next-generation traffic-based services which may be sent via Satellite Radio, or via other data channels, such as two way data networks. It contemplates improving current traffic information offerings in many ways, including:
The following sections introduce some of the key features of Apogee Traffic and lay the groundwork for the more detailed discussions which follow.
Location Referencing
Part I, above, describes aspects of location reference within the service. Because the purpose of the service is to provide information on major, and minor, highways, existing Traffic Messaging Channel tables may be used to provide location references. In an exemplary embodiment of the present invention, Apogee will sub-divide a TMC segment into 8 sub-segments to provide higher spatial resolution than is supported by TMC segments alone; it will encode Alert-C style extent lengths for multiple highway sub-segments reporting similar speed conditions. Retaining TMC tables has three main advantages:
We retain the ability to use other referencing formats as needed, such as, for example, to encode off-highway incidents.
Lanes
In exemplary embodiments of the present invention, Apogee provides the ability to reference lane elements. As shown in
In exemplary embodiments of the present invention, the Junction lane is usually the Right-Hand lane of the main roadbed; it is the lane that may suffer congestion because of vehicles entering or leaving the roadway at an intersection. In cases where the roadway is treated as two separate TMC linears, for example for divided car and truck lanes, the individual linear codes will continue to be used. Ramps (green) are treated separately, as noted below.
Speed Buckets Vs Free-Flow
It is here noted that the Alert-C protocol defines a message code, 124, meaning ‘traffic flowing freely’ without any definition of the term ‘freely’. There is no commonly-agreed TMC/TISA definition for “Traffic Flowing Freely”. This code is used heavily by the traffic providers to reduce message volumes by offering a very broad definition of ‘free-flow’ and aggregating across many segments. The definitions vary according to road class, so we might expect:
Rather than persist with this meaningless definition, Apogee traffic uses explicit speed buckets for all road classes (see the discussion on Speed vs Flow below). The term ‘S/F’ indicating ‘Speed or Flow’ is used in this document to distinguish this approach from the current ‘S&F’ ‘Speed and Flow’ mixture.
Baseline Data
Not all of the data used by Apogee traffic will be transmitted over a Satellite link in real time. We expect TMC location tables to be built into the Navigation Unit, and referenced back to the underlying map database. Apogee will also support historical data that can be used for rough travel-time predictions outside of the more precisely-transmitted service. The historical data can also be pre-loaded into the Navigation Unit, and may be used without reference to the real-time data stream.
Carousels and RFD
In exemplary embodiments of the present invention, Apogee Traffic can use two different methods of data delivery over the satellite broadcast.
Carousels are blocks of data that repeat, in a loop. In order to accept a full carousel the unit must receive the complete set of carousel data in a continuous sequence. While some carousel data may repeat over multiple loops it is more usual for the data to change every couple of loops or so. Data within carousels are grouped into Access Units, and each Access Unit can be processed independently of other Access Units. In particular, Access Units for a particular TMC table or BSA, or set of tables or BSAs can be filtered out from the remaining carousel data without requiring that all table data be fully decoded. Supporting filtering by traffic table within the receiver (module) requires that traffic tables are carried over multiple DMIs.
RFD (Reliable File Delivery) is a method used by Applicant of delivering large amounts of data slowly, without requiring that the receiver operate continuously over the whole of the reception time. It uses an encoding method such that a file of size N (fixed sized) blocks can be recovered from an arbitrary sequence of (N+δ) blocks, where δ is small. However, the file is either received completely, or not at all, and there is no ability to filter only parts of the file, as with the carousel.
It is noted that there is a non-trivial decoding overhead associated with reconstructing an original file from a sequence of RFD blocks, and this may be beyond the capabilities of very low-end consumer units. Therefore, Apogee Traffic Service can be defined to operate without requiring support for RFD, but with the expectation that presentation accuracy may degrade over time for units that do not accept and process updates.
The main use of RFD as described above is to update the set of patterns used for historical data display. For ramp-table updates, the same RFD metadata structure will be used in carousel mode to allow non-GF RFD capable receivers to keep up to date with our ramp definitions. It is noted that various exemplary embodiments may use any convenient method equivalent to RFD.
Service Definition
There are two aspects to the service definition for Apogee Traffic: how to structure the components; and how to divide the components into packages that can be authorized and billed as individual units.
Service Matrix
In exemplary embodiments of the present invention, Apogee Traffic can, for example, comprise some or all of the following service elements:
Where ✓ elements are fully supported and transmitted by the protocol; [✓] elements are not transmitted explicitly but will affect the values of Predictive or Forecast S/F (for example an uncleared major incident would skew predictive values towards ‘congestion’ even though we do not transmit an explicit ‘predicted incidents’ carousel); x elements are not supported; and ✓? implies support for this element may be provided if sufficient data are available.
Geographic Coverage
Legacy traffic services have seen huge increases in coverage. While still at under 10% of the theoretical maximum coverage as defined by the TMC tables, around 60% of the full TMC coverage is for low-functional-class roads for which there is no real basis to justify their inclusion. Even with an explosion in crowd-sourced and telemetry-based probe data, it is still unlikely that we could justify a traffic Speed/Flow service on any of those roads could be justified.
Apogee will remain focused on high-value-travel roads, and the 300,000 miles of high-functional-class roads already covered by data providers. One area where a significant increase in coverage is expected is non-Controlled Access-to-Controlled Access ramps, where we will have to build our own indexes. For this reason we will support a carousel-based (i.e. not the full RFD-GF format) update protocol for those tables.
Service Elements
The following requirements or constraints on the individual service elements pertain:
Real-Time Linear
A ramp component would give S/F data for controlled-access-controlled-access ramps and also possibly lower-class highway-highway ramps.
This is a TMC-based service containing essentially the same information as the current Alert-C service, with improved sub-segment resolution.
This is similar to current services, but includes Apogee improved subsegment resolution, with the added potential to extend to non-TMC-coded roads.
The predictive linear service provides short-term S/F data across all the covered linears. The predictions are derived from current states and environment factors and are expected to be reasonably useful for up to one hour into the future.
In exemplary embodiments of the present invention, Forecast Linear data can extend the predictive data beyond the 1-hour mark, but with less confidence and resolution.
Historical data refers to the selection of a Base Pattern for Speed and Flow data based solely on its position within a semantic grid.
Historical data patterns are linked to service coverage. At any given time, coverage of the historical pattern shall not exceed the coverage of the Real-Time S/F broadcast data. As coverage increases, the patterns will be updated to show the increased coverage. A receiver that does not process the update can continue to show the ‘old’ coverage when using historical data. This ensures that in no case does there appear to be a loss of coverage when moving from historical to real-time data.
Base Data
Base Data refers to the stored patterns of traffic S/F used by the Predictive, Forecast and Historical components of the service.
Apogee traffic naturally falls into two tiers for pricing and access control.
These tiers permit a ‘basic’ and a ‘premium’ service that may be offered. The division of carousels between DMIs and the allocation of groups of DMIs to services (DSIs) and packages is discussed below.
Minimum Receiver Requirements
Apogee is designed to be usable (and offer value to the customer) on a receiver with only minimal capabilities. Specifically:
There are various exemplary levels of implementation arising from the list of service elements:
In exemplary embodiments of the present invention, real-time data are not stored over an engine cycle. For basic products, there is no engine-on display until the first data carousel has been received. Full-Service products may choose to store predictive and forecast data for route recalculations, and display historical or stored-predictive data at engine-on.
Service Rates
The RFD value is set to ensure a maximum delay of 30 days to receive any GF-encoded update for the average commute (2×20 mins/day). The other values are the maximum times after engine-on before the data would be available for display by the application.
The rate at which we issue baseline pattern updates will be either quarterly, if they need to be tied to TMC table releases, or half-yearly in keeping with our other slowly-changing baseline files.
TMC Sub-Segments
In exemplary embodiments of the present invention, Apogee Traffic provides increased spatial resolution, beyond that offered by existing TMC tables, by dividing each segment into a number of sub-segments. This allows:
Preferably, we limit the sub-segment approach to a fixed number of sub-segments per segment, given the following:
These points led to the choice of a fixed number of segments in preferred exemplary embodiments since:
Four sub-segments is not enough for interstate highways, where the length of a segment is typically 5-8 miles. The choice is thus between eight or 16 sub-segments. The value 8 was chosen because: for the vast majority of TMC segments (over 80%) this gives 4-mile or better resolution. This is sufficient to represent accurately the effect of the congestion caused by on- and exit-ramps, as well as a means to locate incidents to +/−200 yards. There is no benefit to using 16 sub-segments for segments under 2 miles, or for very long segments.
Speed vs Flow
As noted above, there is a dichotomy in expanding “Speed and Flow” service to non-controlled-access highways. Does one present speed information, or flow information, to the consumer?
Speed
On a controlled-access highway it is theoretically possible to maintain the posted speed limit across many TMC segments. Individual probe vehicles can provide their transit time for each segment, and we can compute a statistic <stt>tmc the expected segment transit time for each segment. In exemplary embodiments of the present invention, can then apply very simple rules to assume:
So the expected total travel time <ttt> is the sum of the individual segment transit times, and the speed bucket vtmc is the expected mean speed of the vehicle over the segment (of length ltmc).
On non-controlled-access highways there are stretches of roadway where the posted speed limit may be achieved, but also points of enforced delay at traffic lights, yield markers, stop signs etc. Here we must define a realistic minimum segment transit time mstt that is a combination of both factors
mstt=ltmc/vp+δtmc
Where vp is the posted speed limit of the segment and 8 is the delay associated with any enforced stops on that segment. Hence the maximum speed bucket for that segment becomes:
It is possible to estimate utmc from a statistically and historically meaningful distribution of observed speeds and probe-point locations along a single segment, since stop lights and yield signs will generate clusters of sample points while the faster-moving roadbed between intersections will have a more uniform distribution. However it is done, it remains the case that δtmc is a major factor in the equation, for which there is no easy formula.
It is theoretically possible to achieve the posted speed when traffic lights are arranged to create a ‘green wave’ through the linear, effectively setting≡0. If we publish accurate values of vtmc then the calculation of total travel time is the same whether the segments are on controlled-access highways or not.
Flow
Flow is more related to traffic density than to pure speed. We might define flow as the number of vehicles passing a given point per lane per hour:
flowtmc=ρtmc×vtmc
Where ρtmc is the traffic density, in vehicles-per-lane-per-mile and vtmc is the speed bucket for that segment. However these are not [supposed to be] independent variables. If we take the minimum stopping distance between two vehicles at velocity v to be hv yards, and the average minimum car length to be 15 ft (5 yards, length of the Toyota Camry, for example), then the maximum safe traffic density at velocity v is given by:
ρv=(1760−5×ρv)/hv
ρv=1760/(hv+5)
The stopping distances are in yards. The ‘Zero Reaction’ column is the traffic density assuming no driver observes the behavior of the driver in front. If we assume drivers are concentrating we can, for example, support twice this density, which is the value listed in the ρv column.
As the actual density approaches ρv the traffic slows down to maintain a safe stopping distance, thereby reducing flow. If the traffic density approaches ρ0=350 we have a parking lot which can only crawl forwards at very slow speeds.
Congestion is the complement of flow. We can define a simple measure of congestion by:
0 indicates no congestion and 1 indicates maximum congestion (stationary traffic) where ρ is the observed traffic density and ρl is the value of ρv at the posted speed limit. The other interesting value is relative congestion:
cr=ρ/ρv
Where ρv is the maximum supported density at the calculated speed bucket for the segment. If cr is close to, or above, 1 then congestion will increase at that point. If cr is significantly smaller than 1 then the road can sustain higher speeds, all other factors being equal.
It is noted that cr is an order parameter for the approaches that model traffic as analogous to a physical condensed matter system (3- or 4-phase traffic theory) or a travelling wave through a fluid medium (the ‘phantom traffic jam’ effect).
For controlled-access highways, in the absence of other constraints such as road works, the natural tendency is to drive as fast as the traffic density will permit, so there is a simple relation between observed transit time and congestion.
On other highways the difficulty comes because the inter-segment delay δ is a function of traffic density, δ(p) because there comes a point at which the queue at a light does not completely clear during a single green cycle, dramatically increasing the transit time for the segment.
The relationship between congestion and speed is not a direct observable of the system. Vehicle probes indicate speed while sensor loops measure density. Single-loop traffic-flow sensors natively measure occupancy which can be converted in to a estimate of average traffic density over the sampling period, given the loop geometry. This can be converted to speed if the system then assumes an average vehicle length (which it cannot observe). For vehicle probes, with a finite (and small) probe density, true congestion is not an observable of the system.
On a controlled-access highway we can observe vtmc and calculate the appropriate hv and the assumed traffic density ρv that is limiting the speed to vtmc and so calculate c and cr. For non-controlled-access highways we do not know the function δ(p), it depends on the duty cycle of the lights, staggered phasing and other factors. At best c will be a very approximate value.
Current Alert-C implementations do not transmit either c or cr, they only transmit vtmc and expect the receiver to use its knowledge of vp to select an appropriate color for that segment. As the discussion above has demonstrated, this is not a good model for future services.
Thus, in exemplary embodiments of the present invention, Apogee traffic will support both speed bucket indicators and congestion level indicators, using information that is available to the data provider, without requiring knowledge of vp in all receivers.
Free Flow
We to consider the primary purpose of the “Speed or Flow” service. If the primary purpose of the service is to enable navigation units to perform route calculations then:
If the primary purpose is to present a visual indication of congestion to a consumer then we need to define a way to convert vtmc into c for presentation.
In exemplary embodiments of the present invention, the Apogee Traffic service indicates both vtmc and c for a segment, or subsegment, specifically:
For the purpose of transit-time calculation we require fine-grained speed buckets. For linear aggregation the fewer the buckets we have, the better the aggregation. However, these requirements are not mutually exclusive. Thus, in exemplary embodiments of the present invention, Apogee traffic defines fine-grained speed buckets (5 mph granularity) but will not necessarily code all segments at the individual bucket level. An exemplary full 4-bit bucket list can be:
For Real-Time S/F codes 0 and 15 are equivalent, since the NULL pattern is ‘no-coverage’ everywhere. The distinction for non-NULL pattern updates (delta-coding) is described below.
For lower functional-class roads every other bucket can be used, giving 10 mph speed buckets, or group into 15 mph buckets, for example:
Plus codes 0 and 15 for pattern updates when delta-coding.
Congestion Levels
Congestion levels are intended for presentation to a user as colors on a map, unlike speed buckets which are intended to be input to route-time calculations. For most consumer displays, this limits the choices to a small number (usually 3) of colors, usually Red/Orange/Green. To support more advanced displays, congestion is sent as a 3-bit value, defining one of the following colors
Topology
This section serves to illustrate the Apogee approach to topology management and how a receiver can use topology to provide simple and efficient filtering of the input datastream.
Tables
In exemplary embodiments of the present invention, the largest unit of transmission in the Apogee system is the TMC table. Typically this will cover an area of 2 or 3 states.
BSAs
Broadcast Service Areas are the fundamental unit of transmission for most data. A BSA represents a collection of adjoining counties, usually 5 or 6. Since they follow county boundaries, BSAs have irregular shapes. Each Access Unit within the multiplex contains data for a single BSA. SXM will always break data for a flow at a BSA boundaries. However since many linears cross BSA boundaries, it may be necessary to bring in additional BSAs to avoid coverage gaps at the edges of the map. It is also possible to collect S/F data for one or more BSAs and incident-only data for other BSAs, or for the entire table, without requiring the unit to decode all the unwanted S/F data.
Linears
Linears are the fundamental unit of encoding with Apogee. A linear represents a continuous stretch of roadway, typically 20 miles or more, or a ramp, with the same Functional Class along its length. There are also ‘superlinears’ in the TMC tables; they represent long stretches of contiguous linears, for example the whole of an interstate as it passes through the area covered by the table. In the native TMC tables, linears cross BSA boundaries, but in Apogee the linears are re-indexed to limit each linear to a single BSA. By supplying the bounding box for a linear, an application can quickly decide if it needs to process the linear as part of its map area, or not.
Points and Segments
In exemplary embodiments of the present invention, a single linear may be made up of a sequence of segments. A segment may be defined as the section of a roadway lying between two TMC points (with lon/lat coordinates). A point usually represents an intersection on the linear (often an intersection with another TMC-coded linear). Each point may be a member of at most one linear, and has a forward and a backward pointer to the next point in either the positive or the negative flow direction. A simple linear would comprise N segments defined as the roadway lying between (N+1) segments. Each point lies within a single BSA, but a segment may cross a BSA boundary.
Extents
Extents refers to a count of sub-segments starting at a particular point, and continuing for that number of sub-segments. Extents count (sub-)segments, not points, so a simple 6-segment linear requiring 7 points would be painted by extent=(6x8) (assuming 8 sub-segments) from its first point. On a point-by-point coloring scheme this leaves the last point [in that direction] ‘uncolored’. If that is a terminal point (i.e. does not link with another linear) the color is a ‘don't-care’ for the application. Apogee will allow that point to take on the color of the previous segment to support ‘color all points[segments] the same’ in the encoding.
Splitting Linears
To avoid the distracting multiplication-by-8 for sub-segments, this section considers only full-segment extents; the arguments are identical when considering sub-segments. Consider the definition for a linear provided in
The TMC definition of this example would be:
In order to break this into three linears, one in each BSA, we need to consider how the two segments p1-p2 and p4-p5 will be represented and colored, in both the positive and negative direction. The segment is coded as follows, assuming a single speed bucket throughout:
If the left edge of the map MBR lay in B2 somewhere close to the B1-B2 border the application needs to pull in B1 as well as B2 in order to color the p1-p2 segment correctly. This can be handled by Apogee as follows:
Associated with each linear in the Apogee Traffic Table is a bounding-box that can be used for Linear-Bounding-Box filtering as described below. When the bounding box for a linear is calculated, for a particular BSA, all segments within the BSA are fully defined. This means that points p1 and ps are considered to be within BSA2 for the bounding-box calculation. The overall bounding-box for the BSA is the bounding box of all its linears, which is therefore slightly larger than the bounding-box if only the county boundaries were used, as shown in
The Apogee linear bounding boxes for the three BSAs are shown in
The Apogee definition for this linear now looks like:
The same strategy holds for a linear that runs directly into another linear (i.e. if p6 had a forward pointer to another point p7 but that point is in Linear L2, not L1). In this case the filtering would bring in that additional BSA to select L2 and provide the negative-direction coverage of the p7-p6 segment.
There are rare cases of very long segments that cross BSAs without any point in the BSA, as shown in
B1 and B3 would be included as part of a map MBR lying wholly within B2 to ensure the linear is picked up.
When the model is extended to consider sub-segments, the same rules apply. A sub-segment is considered to start at the main segment boundary as far as the splitting calculation is concerned, even if the whole of the sub-segment lies within the ‘other’ BSA. If the 7th and 8th subsegments of p1-p2 were wholly within BSA B2 they are still painted as part of the BSA B1 portion of the linear. This also ensures consistent behavior if different service elements use different numbers of sub-segments in their storage (e.g. storing historical at only the full-segment level).
Since BSAs may be chosen that contribute only a small number of linears, the two-stage approach of BSA and LBB filtering is highly recommended for efficient processing.
While this scheme may appear complicated, the implementation in the receiver is a straightforward hierarchical filtering model:
Algorithms for efficient implementation of these stages are given in the receiver section, below.
Linear-Bounding-Box Filtering (LBB)
In order to provide a filtering capability in the receiver, Apogee traffic encoding maintains the boundaries between linears in its encoding, and also provides an index of which linears are covered by each lane-coverage type. For example, we may define that in table 8, on the main roadbed, linear index 2 corresponds to linear 69 in the TMC table. We also determine the geographic extent of the linear, as a Mean-Bounding-Rectangle:
And the start points in the positive (04256) and negative (04260) directions.
If the extent of the linear does not cross the requested map area it cannot contribute any data, as shown in
As shown in
There are essentially 16 basic types of ramps. For those ramps not coded with TMC codes, we adopt a <TMC LOC>.<RAMP Type> ramp code. Pre & Post refer to the ramp being before or after the interchange, Pos and Neg refer to the roadway's primary direction in the TMC table, using the main road as the reference, as shown in
Encoder System Architecture
Next described is the overall end-to-end architecture of an exemplary provider side of Apogee traffic implementation.
Processing Stages
Traffic modeling and forecasting for Speed/Flow is very similar to how meteorological forecasting is done, which is essentially a three-stage process.
A three-stage process makes a good starting point for traffic data too, as shown in
With reference to
Dividing the process in three components has a number of advantages:
We can decide the way we want to format the data independently of model and filter decisions [though obviously the results are linked together]. Going from pure segments, to pattern+delta to multi-pattern can be developed and evaluated without disturbing an existing service.
The Traffic Model
Applying the three-stage model to Apogee we can refine and expand some of the components. We can also isolate where information is needed. For example we can split the Format block into two sections, one for pattern selection and one for delta-coding, as shown in
These blocks would apply to Predictive or Forecast components that are delta-coded. The criteria for pattern selection may be different if the data are to be delta-coded (minimum bandwidth) or are to be displayed unmodified (minimum perceived error).
We can also split up the filter into two components, one which will take in multiple models and produce a consensus or best view result, and one which will quantize and filter the resulting consensus into the desired granularity, as shown in
This leads to an overall traffic engine architecture providing the opportunity to develop modular approaches to different components, assuming lock down of two key interfaces, the input to the merge/aggregate process and the output of the quantization and filter stage, as shown in
Algorithms and Requirements
In exemplary embodiments of the present invention, for building historical values, either probe/sensor data or unsmoothed model data should be retained for each integration period. Associated with the stored data should be any environment factors (weather, school holiday etc.) that were used to condition the model at that time.
Probes [and Sensors]
We specify the following three requirements for probe processing:
Sensor data shall distinguish between single-loop sensors (where vehicle velocity is only inferred) and more precise dual-loop or Doppler sensors where velocity can be measured directly.
The Mesh Model
In exemplary embodiments of the present invention, the Traffic Model may be run over a finite-element mesh representing the network of roadbeds to be modeled. In exemplary embodiments of the present invention, the mesh granularity shall be at least the larger of 50 m or ⅛ the distance between the TMC points on that road segment. Thus,
The most important part of the production side is the traffic model, or models, that run over the mesh to build the complete state of the network. There are two different aspects to the model, computing the real-time flow, and generating the predictive values.
Table Data
In exemplary embodiments of the present invention, a provider can maintain and supply TMC traffic tables used to convert the Mesh Model into encodable data.
To obtain Real-Time flow, the mesh model may be run in the spatial domain (i.e. T,τ=0) to ‘fill in the gaps’ left by incomplete probe data.
To obtain Predictive Flow, the same model mesh must be run in the temporal domain (following the spatial extension), i.e. with nonzero and increasing r values.
In exemplary embodiments of the present invention, the only realistic approach to forecast (greater than 1 hour into the future) is to treat the values as deviations from the expected historic pattern at that time. The key to making forecast data valuable is to use as much of the currently and predictive information as possible when projecting the deviations.
Historical data mean stored ‘traffic patterns’ and the association of a point in time to a pattern. In exemplary embodiments of the present invention:
It is sometimes the case that historical data is all one has for a given segment of road, at a given time. This occurs when, for example, there is no useable probe data for that road, say, for example, it is an exit ramp from a highway, turnpike or thruway that leads to a suburban shopping district or mall area at 3 AM when all the stores in the district or mall area are long closed for the day. So there is no incident or accident information on that particular segment of road. What do you do? What do you send out? You know, we have to send out something. You have to rely on the historical information at that point. That isn't nothing but it has low confidence.
On the other hand, when dealing with the same or similar highway at peak time, with three cars traversing that particular segment and they are all providing probe values once a second, and they are all highly accurate and they are all correlating to good probe paths and they all correlate with each other, one has a very high confidence that one has a good value at that point for the highway at this peak time. Thus, in addition to actual speed and congestion values obtained by an exemplary system, most raw traffic data providers also provide a confidence interval, or a model confidence value for a given roadway at a given time.
This model confidence value directly affects how much smoothing or aggregation an exemplary system will perform. Smoothing is described in Part III, below, in connection with
Thus, for example, if you have a model that tells an exemplary system that there is a very small segment of congestion in an otherwise uncongested freeway, this could be noise, or it could be the known fact that at certain times of day, although a freeway or highway is in free flow in both directions and not itself congested, people line up in a far right lane, for example, in a queue that comprises dozens of cars, leading to a popular exit.
In terms of the various Apogee Traffic algorithms that are described herein, we describe smoothing an aggregation. There is the option within various exemplary embodiments of the present invention to suppress that small segment of congestion as being possible noise. Or, for example, the option is also available, with the enhanced Apogee resolution to present that that to a driver. The choice of which to do—suppress as noise or present to a user/driver—needs more information than simply the model says it is congested. What is needed to make a rational choice is the “backstory”—the “why” story which is embodied in the confidence level. Thus, the confidence level can be used as a hint whether to include that which increases the message count, which, of course, takes more bits.
Thus, in various exemplary embodiments of the present invention, confidence levels obtained from raw traffic data providers can both be (i) disclosed to drivers/users to supplement a very low signal (or no signal) speed and congestion report, and can also be used in various system algorithms that decide what local anomalies or aberrations to filter out as noise, or to disclose more granularly (and use additional bits to do so) as an actual highly localized traffic condition.
Value Quantization and Pattern Selection
In exemplary embodiments of the present invention, the operation of the smoothing and aggregation portion of the service will have a direct impact on the bandwidth required for the service, and on the perceived accuracy of the data to the consumer when viewing the results.
In exemplary embodiments of the present invention, a number of patterns may be built and used as the basis for forecast and historical models.
Incident data can be supplied for as wide a range of events as possible, not only those lying on roads with Speed/Flow coverage.
Next described is an approach to encoding the different service elements within Apogee Traffic, in a way that fits into the SXM data services. Alternate approaches can, of course, be used for other contexts.
The Data Multiplex
Apogee Traffic can, for example, fit within SXM's current Data Services multiplex. To align this service with other services the data are encoded in SDTP packets with the maximum AU size of 5,120 bytes, protected by the same SDTP checksum and AU CRC-32 codes as all other services. Data will be encoded at the TMC table level, using the AUCNT-of-AUTOT markers if the data for a table does not fit into a single Access Unit.
DSI and DMI Allocation
As with the current service, individual tables are carried on their own DMIs (PSIs). This allows a receiver module to filter data down to an individual table. We need four blocks of DMIs, as follows:
For a total of 98 DMIs to support 32 tables. Within the DMI a carousel identifier can indicate the type of content with the Access Unit, being one of:
In the current SXM case, the contents of Carousels 6 and 7 are fixed by the RFD protocol. By splitting RFD metadata and RFD data into two separate DMIs the handler can continuously monitor the metadata DMI for new files, but only turn on the RFD data DMI when it needs to collect the incoming RFD blocks. Since there is a limit of 63 DMIs per DSI, this maps to three DSIs and two tiers:
If it is desired to separate out Canada this will become 6DSIs. Block D would be included in both the US and Canadian versions of DSI P.
Transport Framing
The multiplex and protocol definitions fix some of the following sizes by their architecture. In this exemplary embodiment:
In this exemplary embodiment, the maximum size of the SDTP payload is 1,024 bytes. The value of 5,120 for the maximum AU size allows a complete 4,096-byte RFD file block to be contained within a single Access Unit, including its standard wrapper.
Use of AUTOT/AUCNT
For the speed/flow data there are fixed break points at BSA boundaries, and these points will not move from one carousel to the next. Therefore there is no reason to require that the data from one BSA come from the same carousel (or integration period) as the data for another BSA. Nor is it required that the predictive data be tied to a particular instance of the real-time data.
Further, the proposed handler(SMS)→Application interface produces notifications at the BSA level, so there is no requirement for the handler to have to wait for ‘a complete carousel’ before issuing notifications. It is up to the application, based on the “You must display received S/F updates within x seconds” requirement, to decide when to request the new data to repaint the screen.
Therefore, there is no need for AUTOT/AUCNT to mark the beginning and end of a carousel. This should simplify the receiver processing, and reduce latency between updates and display. However, we do have to account for the possibility that a single BSA of S/F data could potentially exceed 5,120 bytes.
For construction and incident data, using zipped text, we would be creating and compressing the strings at the table level, so in this case, it is essential that the handler accumulate the full AU group before attempting to decode the data. So:
For forecast data there is no possibility of data for a single BSA requiring more than 5,120 bytes to encode. For patterns and historical data, the BSA division does not arise, because the data are contained within RFD files. For the RFD updates, 5,120 bytes is always sufficient to hold either an RFD data block or a metadata carousel.
Linear Coding
As shown in
The following data can be repeated, linear-by-linear, once for the main roadbed then once per lane type
This is an update protocol, it modifies the ‘current-state’ of the set of linears according to the ‘11’ ‘01’ and ‘10’ codes. The ‘00’ code means “No more updates for this linear”. For Real-Time S/F the current state is “no coverage anywhere”, in which case a ‘00’ leaves any unreferenced segments as uncolored. In cases where the changes are applied to a non-NULL pattern, bucket 15 is used to remove existing coverage, and bucket 0 is used to skip over pattern values which are unchanged.
In exemplary embodiments of the present invention, a linear with only negative coverage would have a ‘10’ code as its first element.
If there are no additional lanes required in the AU, the F+ field for LCOUNT is zero and only the main roadbed is present. There is a 2-bit-per-linear overhead for each lane included in the AU for which there is no coverage for that lane.
The counts of linears with coverage in the table at the end of the document suggests that a careful choice of indexing may be beneficial to the encoding. If we assume that every linear must be present, then for table 8 (Detroit) there will be 873 ‘00’ pairs for the linears with no coverage. If the 87 covered linears were near the front of the index table, the scan could stop when there are no more covered linears in the table. This allows the receiver to end its scan as soon as all the covered linears have been presented, rather than requiring it to skip the 873 linears with no coverage to reach the end of the dataset.
Since was have to index the linears anyway, and fix the index for a particular implementation version, we can choose the linear order best to suit ourselves. As long as we never re-use a linear index [very unlikely] and only add to the end, the indexing will work across all future products.
Real-Time Speed/Flow
Real-Time Speed/Flow data are the bulk of the data transported by the Apogee Traffic service. Of these data, most refer to S/F conditions along the main roadway. Additional lane coverage is only supported for those linears that have the additional lanes. Lane information is transmitted in the same Access Unit as the main roadbed, to remove the need for the application to have to correlate and align traffic data across multiple datasets for the same road segment.
This forms the basis of the S/F data encoding. Each linear is assigned an index in the Access Unit, and the receiver knows the MBR for each linear so can filter at the linear level using simple comparison tests. The details are further explained in the Receiver section below.
Data Encoding
There are currently two possible encoding scheme for real-time S/F data.
The 1-BSA-per-AU model would wrap the linear data block in header and trailer data:
The START field gives the index of the first linear in the encoded data. This is desirable when the total table coverage exceeds 5,120 bytes and it is split between multiple AUs. An example of filtering and processing of this encoding is described more fully in the receiver section below, and the bandwidth estimates for a service based on this coded are addressed at the end of the document.
The AU-CRC is used as the ‘signature for determining if the BSA data have changed since the last received AU.
The BSA-directory mode encodes multiple BSAs in a single AU, with a directory at the top:
In this encoding the SIG field is used to determine if the BSA data have changed or not. By using byte-wide values for the fields, and for the offset, the receiver can locate the start of each BSA using simple pointer arithmetic. This scheme also separates the AU CRC from the individual ‘version’ markers on the BSAs, which is probably a cleaner solution overall.
Bandwidth
Detailed bandwidth calculations are presented below. This section merely illustrates the properties of the encoding, using an exemplary carousel transmitted at 16:00 on 6 Mar. 2011 for table 8 (Detroit/Michigan). The Alert-C encoding for the whole of the table required 2480 bytes to transmit. The cost for the various encodings above are:
If we simply encode the whole of the table, without splitting at BSA boundaries, using the full-scan approach the sample requires 976 bytes to encode. By ordering the linears so the 87 covered linears are at the front of the table, this value is reduced to 757 bytes, corresponding to a saving of 873×2-bit ‘00’ codes. This ordering approach becomes even more significant when we are considering delta-coding where the number of codes is much smaller than for full Real-time S/F.
The 87 covered linears comprise 46 with a constant (free-flow) value on both sides of the linear, and 41 with mixed values, which require 341 ‘01’ and ‘10’ type messages to encode. The 757-byte cost is broken down as follows:
Using BSA-level Access Units, the AU header increases to 5 bytes, and one AU is required for each BSA in which there is a covered linear. The table of ‘Michigan BSAs’ below shows how the whole of table 8 is divided into individual BSAs. Only 17 of these BSA contain covered linears, and the details are given in the ‘BSA Coding’ table below, for a total of 979 bytes.
Although this is a large (30%) overhead, it is entirely accounted for by the additional 16 AUs required to carry the data. This does mean that as the coverage increases, say by a factor of three, the BSA overhead will remain constant in size, and therefore account for only 10% of the data transmission. This is still only 40% of the bandwidth required to carry the Alert-C data.
Using a single AU with a directory-plus-signature header, the value is reduced to 871 bytes which is 35% of the Alert-C value.
Ramp Speed/Flow
Ramps are the short segments of roadway linking major highways. Using the following properties of ramps, and noting with so little data currently available on ramps, and their impact on travel time and user experience, the following assumptions were used:
If most cases, we are unlikely to get very accurate speed bucket data for ramps, and 16 possible values is excessive. Hence, we focus on the ‘congestion indicator’ for ramps. If a routing engine wishes to use these indicators to weight a ramp more or less favorably then it can choose to do so. The ramp coding schemes use only 2 bits per ramp to indicate:
For transit-time calculation, the difference between green (say 50 mph) and orange (20 mph) for a ½ mile ramp is only 36 s vs 90 s, whereas stop-and-go can easily extend that to minutes or tens of minutes. This indicates that for short ramps (those that are likely to have transit speeds significantly below highway speeds) only the very heavy congestion will materially affect the route calculation, but the color indicator will give value for the observing consumer.
It is also very likely that most ramps are in a ‘default’ state that can be inferred from the surrounding conditions, for example:
In exemplary embodiments of the present invention, this algorithm can be enabled as an alternative interpretation of ‘0’ instead of ‘do not color’.
CA-CA Ramps
These are the ramps for which we can currently obtain data. There are approximately 11,000 of these ramps across the country, and using conventional TMC-style style coding for individual ramp flow will be very cumbersome if it requires one message element per ramp.
Since these are only the CA-CA ramps, they are not clustered along linears, so the linear-indexing scheme use for main S/F will not work. We can still offer BSA-level clustering of ramp states. This can be in separate AUs if we have a large number of ramps (when combined with ‘other ramps’ below) or by indexing into a single AU with ramps grouped by BSA,
Other Ramps
There are many significant ramp locations that fall outside the CA-CA ramp definition, for example the 1-95 to US.1 intersections. However, they are associated with TMC location points. We would have to develop our own tables if we are going to support other ramps within the service. Using the ramp topology defined above we can encode each ramp as a TMC.ramp-type value, indexed from the main TMC point.
Ramp Coding
We assume that we can reverse-engineer the ramp topology data and associate each ramp with a TMC point location on a linear. This gives the following structure:
The ramp data are then transmitted in linear+point+ramp order, 2 bits per ramp. From the linear index the receiver can perform LBB filtering as with S/F data and skip over the number of ramps in that linear. It can also do a simple point-in-rectangle check on each point. We may wish to transmit two sets of ramp data, one for the CA-CA ramps and a potentially much larger set of the other ramps.
Construction Events
Construction Events are typically long-lasting, unlike incidents. Since construction events can occur at any place, even on roads with no S/F coverage, and are not correlated, the encoding reverts back to the pure TMC reference model, but using the extended precision sub-segment definition to improve resolution. There is no filtering support for message rejection below the table level.
Construction Events occupy almost 50% of the feed volume in the research feed we are analyzing. Partly this figure is so high because the events are present in every carousel. Since these are usually long-lasting events, there is some bandwidth savings to be gained by sending construction events separately from other incidents, and more slowly.
The Alert-C coding of construction relies on the event code to carry a multitude of semantic markers, for example “Q sets of roadworks during off-peak periods”, that requires essentially message-by-message handling to interpret, particularly if the message is being used to adjust route or timing calculation. Apogee construction events continue to use the Alert-C style code point, which is useful for selecting an icon for a screen display, but they also contain a semantic breakdown of some of the fields to assist in automated processing of the event. This also allows multiple ‘roadworks’ events from different messages classes to be combined into a single coherent representation.
Events that Cross BSA Boundaries
The Apogee architecture allows the application to filter at the BSA level. Therefore any construction event (or accident) that has an extent that crosses multiple BSAs must be included in each BSA (or it might get filtered out).
If the event lies outside the set BSAs that an application is processing then it is outside of the product's area of interest. It is therefore unimportant, or even impossible, accurately to place the start location of the event (because the start location is in the adjacent BSA which is outside the area of interest). However, the portion of the extent that lies within the BSA being processed (which is within the area of interest) should be rendered.
For events that have their head location within the BSA of interest but extend into adjacent BSAs outside of the area of interest, the rendering should terminate at the BSA boundary (because beyond that would be outside of the area of interest).
However, we must also ensure that a single event does not become represented multiple times, with multiple icons or popups, if more than one of the BSAs through which it passes is being processed by the application. These cases are handled by the F+HEAD element in the construction encoding (and the HEAD control operation in incident encoding) as follows:
At the Application level:
These protocol elements and rules permit a long event to be split and filtered at each BSA boundary without causing additional icons to appear on the screen.
Construction Encoding
In exemplary embodiments of the present invention, each construction event may be coded as follows:
That puts a construction message around 40 bits, including all our extended references. The TEXT component is intended to add ‘color’ to the construction message, without duplicating the location or construction event. The value is an byte offset into a table of strings, transmitted as part of the construction data using a gzip-compressed section of the Access Unit. The overall structure of the construction AU-group then becomes:
In order to maximize the compression, the string table is compressed at the table layer, so construction messages will always be sent out as multiple-AU groups where the F+ fields link together the individual AUs.
For AUs other than the first (or only) AU, the start of the AU contains only the AU Header and F+ fields, plus padding to a byte boundary. The receiver shall:
We can probably limit the maximum size of a single TMC table of data to 4 AUs (20,480 bytes), based on the numbers we have seen so far.
Incidents
The Incident component of Apogee Traffic is the most open-ended aspect of the service, after S/F and Construction. Analysis of the research feed from NavTeq (trafficML) shown in the “Events” tables at the end of the document show that there are many more events in their full coverage than we are used to seeing in the Alert-C data.
On the one hand, Alert-C defines around 2,000 potential incident types with parameters to display additional information (counts of vehicles involved etc.). On the other hand our 1-day AlertOC sample contains under 50 distinct message codes, and no parameters, while the trafficML feed contains only 110 distinct codes, and only 93 if the construction events are removed. However, these events do contain text phrases that can be used to augment the meager Alert-Ccodes.
Design Assumptions
If we take the view that our incident coverage will include the full trafficML coverage, we can start with the following assumptions to guide the design:
Both Alert-C and TPEG consider their encoding to be based around ‘phrases’ that can be put together to produce an incident description. Apogee also follows this approach and uses the same coding syntax that we use for the Weather Alerts Data Service, with appropriate changes to accommodate the different location referencing schemes. The main difference from the Weather Service is that a Phrase Table is not used; instead text strings are encoded as byte offsets into a gzipped string table in the same format described above for Construction messages.
Each table-level component comprises a list of messages. Each message comprises a mandatory location element and zero-or-more control elements followed by an end marker.
Each message can, for example, be then coded as follows:
Each CONTROL operation comprises a four-bit Operation Code and optional parameters. The current list of control operations is:
The FMT field is a 4-bit field used to control the presentation of the element on a display screen:
The signature marker on END may be required if we want to detect when new incidents arrive (for text-to-speech) for example, similar to the requirement for Weather Alerts.
The Offset control operation allows us to specify an arbitrary point location with respect to an pre-existing TMC point, without requiring that the incident be associated with the point. The offset is coded as:
The Location control allows an incident to span multiple TMCs, as in the example of the Fire at a Mall in the Location Reference document. As an alternative, the Radius control gives a radius for the affected incident, up to 3.2 miles using 5 bits.
The HEAD operation is used to define the starting point of an incident when it lies outside the current BSA, as described in the construction section above.
The overall structure of the incident data carousel is then identical to the structure defined above for the construction data, and the same rules for AUTOT/AUCNT and zip string processing apply.
Predictive Speed/Flow
Predictive S/F is a short-term projection of likely traffic conditions based on current conditions, environment, and history. Typically predictive values decay towards historical the further out in time that the projection extends. Apogee traffic limits predictive to no more than 1 hour from current. Predictive values are coded in exactly the same way as Real-Time S/F, except that the encoding assumes that the segments have already been colored with the previous set of buckets. The first predictive (+15 or +20 mins) is coded as a difference from the latest real-time, the second predictive (+30 or +40 mins) is coded as the difference from the first predictive, and so on.
This coding method explains the need for the ‘skip’ code, code 0, in the bucket table. It directs the receiver to leave the underlying values alone. Other values replace the previous codes with the encoded value. There is, of course, no requirement that the original extents match the replacement extents, only that the correct number of extents are processed. An end marker ‘00’ signifying ‘end of linear’ means that all other segments retain their original values—it does not mean ‘paint the segment white’ which is the purpose of code 15 in the bucket table.
Forecast Speed/Flow
As we move more than 1 hour away from real time, the accuracy of a full predictive dataset decreases, and the effort of maintaining multiple pattern deltas increases. However it is likely that knowledge of current conditions may be able to suggest a better forecast than relying purely on historical data. The essence of the forecast S/F service is to suggest a ‘most likely’ pattern for a time in the future, selected from a set of previously stored patterns, and optionally encode significant changes from that pattern.
Coding
Forecast data provides 9 forecast points at 15 min intervals from +1 hr out to +3 hr out in time from the current conditions, encoded in one or more Access Units as follows:
The starting offset of each pattern in the Access Unit is determined by the index position in the initial BSA directory. Each PATT references one of 256 stored base historical patterns.
Base Historical Patterns
The Historical Traffic Pattern element assigns semantics to some of the stored base patterns to they can be used to give rough approximations of traffic conditions beyond the Forecast Period. This aspect of the service is also usable without any Real-Time service, using a static table that can be built in to the application at manufacture. Hence the historical data only references stored patterns, unlike the forecast data which may modify the pattern to produce a result closer to the predicted state.
Because it only makes sense to update the mapping table if is it also possible to update the stored pattern table, the mapping can be sent over RFD, and linked to specific table versions. Each map is a list of 960 8-bit table references, comprising:
We can then link a particular slot (8:15 am, weekday etc.) to a particular Index.Version for each BSA in the table.
Patterns
Finally, we also have the base patterns themselves. Apogee supports up to 256 individual base patterns for each table. The patterns are encoded using the same method as Real-Time S/F. Groups of patterns are sent to the receiver using RFD. Because we are using RFD, we can ensure that groups of patterns and the associated mappings are applied in the correct order.
Pattern Encoding
A pattern for a table is defined as a BSA directory for all of the BSAs in that table. If we define and update patterns at the table level (rather than the country level) the RFD update structure for pattern updates would then become:
Pattern Metrics
There are three possible metrics to use when choosing a set of base patterns (or groups of patterns using a combination of metrics).
The choice of metric depends on the purpose of the pattern. For predictive data we require patterns with low coding overhead (M1). For historical data, where the pattern is used unmodified we require low perceived error (M3) or its statistically valid relative M2.
We may use one method, e.g. M2, to build a set of base patterns because of its known mathematical stability, but other metrics, M1 or M3, to select the most appropriate pattern for a given purpose.
Processing
This set of encodings, using BSA directories, provides a common processing path for all service elements whether real-time, predictive, forecast or historical with only a single representation of the linear-level encoding:
The common decoder is the pseudocode (LBB filtering and bucket coloring) described in the main document.
Provider Questions
The following sections covers issues that may be asked of a provider to coordinate with an exemplary embodiment or implementation.
Probes [and Sensors]
Assume we have already covered the value metrics for their probes:
Assuming that the traffic model runs over some form of finite-element linear mesh and that the probe and sensor values are used to seed the grid over which some form of evolutionary equations are run:
To obtain Real-Time flow, the mesh model must be run in the spatial domain (i.e. T,τ=0) to ‘fill in the gaps’ left by incomplete probe data:
To obtain Predictive Flow, the same model mesh must be run in the temporal domain (following the spatial extension), i.e. with nonzero and increasing r values.
Assuming that the only realistic approach to forecast (greater than 1 hour into the future) is to treat the values as deviations from the expected historic pattern at that time.
Assuming historical to mean stored ‘traffic patterns’, and the association of a point in time to a pattern:
If the provider is also performing quantization:
Next described are aspects of receiver design and operation needed to implement Apogee Traffic in various exemplary embodiments.
Receiver Complexity
It is not easy to provide a single measure of ‘receiver complexity’, since varying tradeoffs of CPU/Memory/Disk may be made in the design space.
The dashed line linking the TMC tables to the filtering code indicates that if linear-level filtering is done in the protocol handler, then it will require access to the TNC tables. If, as is proposed below, that level of filtering is handled by the application, the protocol handler can operate with requiring access to the TMC location tables.
The Module and the BitStream
In exemplary embodiments of the present invention, the module is responsible for handling the subscription and entitlement components of Apogee, for receiving and decoding the overlay satellite stream, for extracting and validating SDTP packets and for filtering down to only those DMIs required by SMS.
Protocol Handler
Similarly, the Protocol Handler is responsible for the bulk of the protocol interpretation for Apogee traffic. We need to ensure that marketing requirements are met for the all the service and resource constraints for the end-to-end system, specifically dynamic memory, CPU cycles and non-volatile storage. SXM will continue to offer SMS as its preferred method for parsing and filtering Apogee Traffic data; applications are free to choose their own implementation, subject to UIRR and TA requirements. In this case the following sections may be taken as ‘best practice’ guidelines for that implementation. We will decide how best to encourage best practices through documentation, flowcharts, pseudo-code, code fragments, SDKs all the way up to a full implementation such as SMS.
The Handler will need to have permanent storage for the following information:
Basic TMC Tables
These are minimally required in order to follow the forward and backward pointers that link TMC point locations into linears. This table may be shared with the Application, in which case the number of times the tables must be consulted is a resource that needs to be quantified (and minimized). If this is not possible, the handler would need to obtain a second copy of the tables for its use.
Extended TMC Tables
It may, in various exemplary embodiments, be useful to supply additional data related to TMC tables for Apogee Traffic to be usable, or decodable. Possible extensions to the basic TMC tables include:
In exemplary embodiments of the present invention, it is possible that all these additional data may be integrated into a single extended TMC table by a data provider. Whether they are separate tables or part of the TMC baseline they may be stored for use by the handler.
Patterns
A pattern is a way of defining an initial S/F state of a traffic market. Patterns are a valuable tool in reducing the information that needs to be carried in the bitstream, as well as providing fall-back points when data are unavailable. In order to limit the need for a receiver to support pattern data, and pattern updates, patterns are used only as an approximation to the traffic state at a time that is outside the predictive window [i.e. history as a predictor of future].
The main factor in determining the size of a pattern is the granularity with which the pattern is stored. To be useful in the historical-as-predictive function there are only two viable levels of granularity:
Even though we have limited the number of distinct patterns per table to 256, and the true number may be much less.
RFD Update
In exemplary embodiments of the present invention, RFD may be used to present updates to stored data. This requires storage for incoming RFD blocks, up to the size of the file being updated, plus the overhead for the RFD metadata and equation coefficients used to reconstruct the file. For ramp data we will send the file ‘carousel’ form, not GF-encoded, so the handler need only store the file blocks as they arrive, and maintain the mask of which blocks are still outstanding.
Other Data
One issue is whether or not to store any of the dynamic data. There are only two types of dynamic data that may, for example, be stored.
There are many ramifications in the handler when dynamic data need to be stored. Flash write time, flash wear, and stability across power cycles all argue for writing as little data to disk as possible. When we impose the requirement that we do not store identical data over the top of itself we start to need version markers on data carousels. The impact of this requirement is not so much on the bitstream as on the failover capabilities on the broadcast side (the feeder). A true information-preserving failover is almost impossible to support given that systems or network links can fail at any time. Alternative solutions, like comparing checksums, require that the data carousels are constructed identically every time, i.e. that event messages are always inserted in the same order, which would place additional restrictions on the output format from the provider.
CPU and Memory
These requirements tend to be linked since various techniques can trade one off against the other. The main variables are:
A perfect transmission and reception system, cannot be assumed. We can, however, assume that an access unit will be received completely and without error, or not at all. The atomic unit of presentation is the BSA. Since the encoding boundaries between the BSAs are precisely defined the application can use BSA data from different carousel cycles with causing dropouts or ‘come-and-go’ flow on the display. It is also possible to mix historical data for one BSA with live data from another BSA during the initial engine-on startup. It is not possible to go back from live to historical, since the historical data may have less coverage than the live data.
In the case when all the data for a BSA is contained within a single Access Unit, newer data can immediately replace cached older data. If the BSA data are split over multiple Access Units, that BSA will need to be double-buffered and a complete AU collected before it can replace the older data.
Persistence
The following table states the persistent requirements for the different data elements in the service. Persistence means persistence across engine (power) cycles. All data are expected to persist while power is applied to the receiver, there are no data timeouts in Apogee.
‘No’ means that data shall never persist across an engine/power cycle. ‘Optional’ means that the application may choose to retain those data elements. ‘Yes’ means that an application that implements those service elements is required to store the data, and any updates to the data received over the air.
It is here noted that it is possible to implement an Apogee traffic service without using writable persistent storage, using only the tables (TMC, ramps, patterns etc.) built in to the system at the time of manufacture.
LBB Filtering
Linear-Bounding-Box Filtering is the means by which the handler can reduce the processing requirements for clipping a full BSA dataset down to a map area, expressed as a geographic MBR. The encoding for this method was presented above, but without any justification for its utility, which is now given here.
Firstly, we have removed any requirement for filtering to a precise radius as part of the handler functionality. We require only filtering down to an arbitrary geographic rectangle. Using a map rectangle rather than a 50-mile circle is more natural for a map display. Given a point and radius the extent of the MBR latitude is ±180r/3963π degrees and the extent of the MBR longitude is ±180r/3963π.cos(φ) where φ is the latitude of the center point and r is the desired coverage radius.
In considering the filtering algorithm, we must accept that the handler cannot be expected to do a perfect job of guaranteeing that every single linear within the map MBR will be colored, and only those segments. Without using the full-resolution map database it cannot determine if a linear with endpoints outside the MBR crosses into the MBR or not. The handler can choose between three options:
In exemplary embodiments of the present invention, all three filtering methods can be implemented using only simple comparisons once the map MBR has been established. If we represent the MBR as a structure with 4 fixed-point values (32 bit integers are adequate for this operation allowing 6 decimal places of accuracy) we have:
Then determining if a point lies within the MBR is simply:
The following test will detect all lines that either cross or come ‘close to’ the map MBR:
Where sgn is the signum (signof) function. Finally, we have the basic linear-bounding-box filter, which selects only those linears that may potentially have points within the map MBR. Given two MBRs the test for this condition is:
All these tests using simple arithmetic (or even just comparisons if you wish to code sign that way) and no trigonometric functions.
The other operation not covered above is the conversion of the MBR latitude to MBR longitude by division by cos(φ). A reasonable fixed-point representation for geographic co-ordinates is to use 20 bits of binary precision for the floating part, leaving 11 for the integer and 1 bit for the sign. This gives an accuracy of 1/1,000,000 degree which is more than adequate for traffic displays. The calculation of the MBR latitude is quite easy, it is 15160r where r is in miles, or 758000/1048576 for 50 miles. We can build a table of 1/cos(φ) for integer values of degrees in the useful range (0 . . . 80° N). For 42°N (near Detroit), the value is 1.3456. Writing this as 1+354/1024 we have the integer calculation:
758000×1+(758000×354>>10)=1020043
Which is within 1% of the true value, even at 42.5°
Using a point in the outskirts of Detroit, for example, and all the S/F data in table 8 for a single day, filtering all the Alert-C coded points one at a time involved examining 2,678,671 individual TMC locations (including delete processing). Using the LBB encoding and filtering required examination of only 1,219,477 individual locations, or 45.5% of the encoded data.
Table Data
In exemplary embodiments of the present invention, to implement a filtering algorithm we need to supply the MBRs for each linear in the BSA, and index the linears for reference in the broadcast, giving a structure that would look like:
Here table 8 extends over a certain MBR and contains a number of BSAs. The first BSA has its own MBR and contains a single county, and a number of linears. The first linear is linear 00472 in the TMC table and the portion within BSA 7 extends over a certain MBR. The portion within the BSA covers points [8906 . . . 5729] in the TMC table and those points and their linkage are given below the Linear.
These data amount to little more than a re-ordering of the existing TMC table, and the addition of the MBR (M=) county code (F=) and point range (P=) to the relevant rows, which can be accomplished by adding a single extra column to the standard TMC CSV (or XLS) files.
Next, described are the various components of the Apogee filter.
Setting the Filter
In exemplary embodiments of the present invention, the filter is a set of tables and BSA numbers and bit values, one bit per linear, that says if the linear is to be included (‘1’) or excluded (‘0) from processing. It is recomputed only when the application requests a new map coverage area. An exemplary process is:
This completes the filter setting. The receiver then subscribes to the set of DMIs required to collect all the data for the tables marked for collection.
Duplicate Detection
Typically Real-Time S/F data are recalculated every 150-180 seconds, so the same carousel will be transmitted 3 or 4 times before it changes (assuming a target of <60 seconds for the S/F data repeat rate). If the handler has already processed one instance of the carousel it does not need to check and decode an identical copy. It can discard an Access Unit as a duplicate if [and only if]:
These checks can all be made on the AU wrapper and header, without requiring that the contents be decoded. If it is determined that the AU has changed, then each BSA can be examined using the signature field in the header (for the BSA-directory encoding method). If the signature has not changed, then that BSA need not be processed again. Because extents never cross BSA boundaries, the state of those linears will be identical even if other BSAs in the Access Unit have different data.
Broadcast Encoding
As described above, data for each linear in the table are presented in the order defined by the linear index. Each linear comprises either:
An example for four linears might look like:
Where speed bucket 8 is 45 mph, and 1 is high stop-and-go-traffic. Note the extents are given in ⅛-segment units according to the sub-segmentation methodology.
SDTP Handling
In exemplary embodiments of the present invention, efficient filtering of the incoming SDTP packet stream, the following may be performed. Assume that we run one instance of the following state machine per DMI:
S and E refer to SDTP.start_flag and SDTP.end_flag respectively being set in the packet header.
Where
Filter Operation
Data Processing
In exemplary embodiments of the present invention, there can be two different models for data processing. The first model assumes that all the processing is performed within a single application (i.e. the handler passes up a complete BSA bitstream to the application). In this model, if a linear does not need to be processed it can be skipped over directly in the data stream, without reference to any other tables or calculation:
For each linear that needs to be processed, the linear index table gives the starting TMC locations for the positive and negative directions. The usual TMC table point linkage then gives all the intermediate points to complete the linear. In pseudo-code this appears as:
The ‘set’ operations depend on how the data are to be delivered from the handler to the application. They also require traversing the TMC table at the sub-segment boundaries to move to the next segment in the appropriate direction. The example code assumes filtering for the minimum-point option, but the filtering calls can easily be substituted to achieve either of the other two methods.
In a second model, the handler extracts and formats the data for the application, without filtering to the linear level. This model is suitable for handlers like SMS, for example, which need to avoid accessing the TMC tables to perform LBB filtering, based on the Data Partitioning section below. This requires an application data model and the definition of an interface between the handler and the application. One such combination is offered below.
Data Partitioning
One of the goals of processing architecture is to localize accesses to stored data in such a way as to minimize cross-component data accesses that require data locks, particularly across the handler-application interface. This leads to the partition depicted in
Within this partitioning, the Handler component ‘owns’ the Stored Pattern Table and the Map to those patterns that is the Historical Data element of the service. Both of these are updated using RFD. The Handler also owns the String Tables used to convert incident and construction messages into human-readable text. This is extracted in real time from the construction and incident data carousels.
The application owns the TMC tables built-in to the product at manufacture, and not subsequently updated. It also owns the Ramp location table, which is updated by RFD. Assuming that the Handler is responsible for all of the RFD decoding (if the application developers choose to include update-over-RFD in their product), this requires the following logic in the Handler-RFD interface.
The Data Model described below also conforms to this partitioning of the access to stored data. None of the Speed and Flow Data Elements require access to the TMC table in order to construct the object (for example it is not necessary to know how many TMC points are contained along a linear to build a complete Linear element).
Application Data Model
The complete set of Speed and Flow Elements may be constructed from the following data model:
The Service Elements are constructed from these basic structures as follows:
The Data Model for ramps comprises the following elements:
Incident and Construction Data are transmitted as packed versions of a data structure as defined in the Information Elements section above.
In addition to the transmitted Data Elements described above there are also the updatable tables and non-updatable tables which share indices with the transmitted elements:
The Data Model and Data Partition also determine, to a large extent, the interface between the Handler and the Application and the nature of the objects that can be shared across the interface. [Note, this is not to say the interface must be ‘Object-Oriented’, only that the collection of information and how it can be referenced will have certain constraints].
Filtering
Because the handler does not have access to the spatial topology of the TMC table, it cannot perform spatial filtering of the incoming data. It is the responsibility of the Application to decide which BSAs it wishes to monitor and inform the Handler. The Application is also responsible for applying the LBB filter (if it so chooses) to the individual linears in the BSA, or for selecting only a subset of the Linears based on a map zoom level etc. To assist the Application, the Handler returns an indication that a particular BSA has been updated, and then allows essentially random (indexed) access to the Linear data, without requiring the Application to iterate over all the SpeedFlow data for unwanted linears.
Setup
Where type is one of the Service offerings and bsa is a Table.Bsa index (determined from the TMC/BSA table).
Dynamic Data Delivery
Where bsadata is a reference handle to a Bsa, RampBsa, IncidentBsa or ConstructionBsa object, inferred from the type value on the ‘available’ indication. For predictive data, the tau value indicates which of the (2, 3 or 4) future predictions should be accessed. For incidents and construction, since there is no meaningful external index, the events are simply returned one-at-a-time through an iterator.
Pattern Data
For the stored-pattern data, the first step is to obtain a pattern index and then convert that into a bsadata object reference.
The linear data can then be extracted from the patter using the linear operation above.
Updates
If the handler is processing RFD updates, a set of indications will inform the application about changes to the stored data:
These indications would cause the application to refresh any stored information it has that resulted from use of the forecast or historical data. For ramps, the application should secure the ramp data to disk, then acknowledge the update with a ramps-updated operation.
String Table Lookup
Because the Handler owns the String Tables it is responsible for expanding the compressed text in construction and incident data objects:
Where object is an Incident or Construction Data Object returned by the iterator.
The Application
In exemplary embodiments of the present invention, the following include some of the functions of the display application and how they might affect the design. The application is expected to:
The following guidance will help application developers make the best use of Apogee data.
Historical data may be used for route and travel-time calculations immediately following engine-on, but the values should be re-calculated once the Real-Time data are available.
A sufficiently powerful Navigation Unit may attempt to display data from more than one S/F dataset at a time, for example by blending Real-Time and Predictive values onto the same screen. Otherwise the recommended way to present these data is through a ‘time dial’ described below.
Scale-Based Displays
Noting that Apogee transmits a lot of data, more than can be displayed on a small screen at over a large coverage area, the application should apply ‘intelligent’ filters to the data to decide what is appropriate to display at each zoom-level on a map. The following levels are possible:
Similarly, per-lane views may only be appropriate in ground-view style navigation map displays as intersections are being displayed for turn-by-turn directions.
The Time Dial
In exemplary embodiments of the present invention, a simple way to display non-Real-Time S/F data is through a “Time-Dial” where the user can scroll the application forwards in time, and the screen will display coverage data from the most appropriate dataset.
Preferably the Time-Dial knob can operate in either 10 min or 15 min increments, but not anything smaller. In exemplary embodiments of the present invention, the datasets can be used as follows:
Filtering
Filtering and smoothing the data points produced by the model may reduce the bandwidth required to encode the data, and also reduce any barber-pole striping on the roadway which may be distracting to the driver. There are two main techniques that can be applied to the raw S/F data.
Spike Removal
In exemplary embodiments of the present invention, removing ‘small’ spikes in the data improves aggregation, for example, as shown in
In the upper line of
The current algorithm for spike removal first requires that
and then that the filtered point (v−1+2v0+v+1)/4 be equal to either v−1 or v+1 Otherwise if the spike is sharper, it is retained.
In exemplary embodiments of the present invention, a better algorithm would take into account the relative confidence values of the three points. Essentially we would not want to suppress a spike generated by probe data when surrounded only by historical approximations. If the confidence values for the three points are ρ−1, ρ0 and ρ+1 then a better filtered value would be (ρ−1v−1+2ρ0v0+ρ+1v+1)/(ρ−1+2ρ0+ρ+1) which can then be compared to v−1 or v+1. However, without knowing the mathematical derivation of the ρ values, we cannot assign any meaning to this value, other than a subjective belief that it is ‘better’ than ignoring ρ entirely.
Mean-Value Smoothing
In exemplary embodiments of the present invention, the purpose of mean-value smoothing is to reduce low-amplitude ripples in the data by replacing a sequence of values by their mean bucket value. Since these values can then be aggregated into a single ‘message’, it reduces the total number of messages at the expense of allowing small errors in buckets over a long range of the linear, as shown in
Consider a sequence of data values {xj}, and let └xj┘ be the bucket value assigned to that value, as shown above (blue dots are bucket values). The values have a mean
∀xj∈{x}:|└xj┌−└
i.e. the algorithm tolerates an error ≤1 bucket value in each direction from the proposed mean value. All the points in the set can be replaced by the red value and no value will have an error of more than one bucket from its ‘true’ position. Since the test is on the range of values, the set {x} can be replaced by its extreme values, so the set is smoothable iff:
max(└xj┘)−└
The filter accumulates a set of data points and their minimum, mean and maximum values. The next point on the linear is accepted into the set iff the new mean lies within ±1 of the new maximum and minimum (i.e. the new set is still smoothable). Otherwise all the points in the current set of data are replaced with the current mean and the accumulation process starts again.
Bandwidth Estimates and Analyses
Next described are detailed analyses of the encoding approach and the resulting estimates for bandwidth and future growth.
Summary of Results
The following two tables summarize results of encoding the 300 kmiles of trafficML feed. The sample data used for the detailed analysis comprise:
The estimates for the various service elements are as follows:
These values assume the carousel rates used in the service definition section above.
Modifiers to the Bandwidth Calculation
Encoding the Current Broadcast
To understand how those figures relate to the current SiriusXM traffic services, for example, we can compare the current SXM broadcast to the coding scheme described above.
The ‘Recoding Current’ table below shows the before-and-after AU sizes. The first number is the number of bytes in the current carousel, including SDTP overhead. The results are summarized by traffic table below:
Improving Resolution
Since we have improved the spatial resolution of the service by introducing the sub-segment concept, we need to estimate how many additional messages might be introduced as a result of increased resolution.
Looking at the nature of the messages in the carousel, there are a number of cases where the speed bucket jumps by more than one bucket between adjacent TMC segments. If we assume that sub-segmenting does not introduce any additional transitions within an extent, then we need to estimate how many additional messages might be generated during the large skips.
Since we would be able to choose the amount of smoothing applied to the data before broadcast, we might choose between one of the following two options:
With option 1, a jump of 76-72 would generate 3 additional messages (75, 74, 73). With option 2 it would only generate one additional message (74). Option 2 makes sense when the speed change really is quite sharp, when approaching or leaving an area of high congestion. Option 1 may better represent the ‘inchworm’ condition John describes where there is a slow slowdown and buildup of speed.
Using ‘Detroit 16:00’ as the sample, implementing option 1 requires an additional 211 transitions in the data stream. Obviously none of these affect the ‘all-segments-the-same’ coding, so they require an additional:
211×16=3376 bits=422 bytes
Option 2, where steep transitions are aggregated into fewer steps, required 92 transitions or:
92×16=1472 bits=184 bytes
These numbers suggest that LBB coding by BSA at full resolution would require approximately ⅓-½ of the bandwidth used by Alert-C for the same carousel rates.
TrafficML Coverage Analysis
This analysis is based on the Michigan DOT database of roadways in the state. Although table 8 extends into Ohio covering Toledo, the bulk of the road miles lies within Michigan, but these figures should be treated as being ±5% accurate because of the additional out-of-state coverage.
There are a total of 776,038 roadline records in the whole of the state. The geospatial shape file contains roughly 4,400,000 points so each record represents a line with about 3 internal points (5.5 points per line). Lines that connect have duplicate endpoints, so the number of distinct mesh points would be closer to 3,600,000. The vast majority of those points are on non-TMC coded roads, as shown in the figures in the Topology section above.
The database (.dbf) file categorizes each map segment in two different ways, according to National Function Class (USDOT system) and Framework Classification Code. The following table shows the breakdown of Michigan DOT map segments by National Function Class
The NFC codes were used to color the map above, NFC-1 roads are wide blue, NFC-2 roads are medium green, NFC-3 roads are medium red, NFC-4 roads are narrow red and NFC-5 and above are narrow grey.
The FCC codes are more detailed and allow us to estimate ramp counts and other data. The following tables enumerate each of the major classifications and their subclasses.
A0 describes roads under construction
A1 describes Limited-Access Highways
A2 describes US and State Highways
A3 describes arterials and collectors based on the NFC system
A4 describes non-certified roads
A6 describes roads with special characteristics or purposes
A7 describes non-vehicular ‘roads’
A9 describes artificial road features not seen on a map
The TMC Table 8 breaks down into the following data points
A table at the end of the document correlates the NFC and FCC encodings for the dataset.
Ramps
It is noted that the TMC table identifies 137 points as P1.1, or interstate—interstate intersections. If there are two TMC points per intersection (one on each roadbed), that means there are about 68 interstate intersections in the table. With only 385 ramp points/linears, that indicates an average of only 5.5 ramps per intersection.
This number cannot be compared directly to the count of A13 values in the DOT table because the shape file uses multiple segments to represent a single ramp (for example to render accurately the cloverleaf shape). The 1-275/1-95 intersection has six ramps, but 13 A13 segments, and we can average 2-3 segments per ramp.
There are 15 separate intersections covered in the same area as the TMC map above.
The DOT table does not distinguish ramps between interstates from other ramps, but comparing a sample of the intersections between the TMC and DOT tables, there are approximately 2-3×the number of DOT segments used to code the same intersection. So from the DOT tables we might expect the true number of ramps to be around 5,200/2.5, or 5,500/2.5 if we include the A23 codes as well (that is around 2,200 ramps). This suggests we would expect a 5.5× increase in data if we coded all the ramps to and from the freeways in the state (which agrees with the 15:3 ratio from the Ann Arbor map).
CA-CA Ramps
Table 8 has fewer than CA-CA 400 ramps, which will take 100 bytes to encode at 2 bits/ramp. The BSA directory structure [Id+Offset+Signature] takes 5 bytes per BSA, or 100 bytes if the ramps span 20 BSAs. Using the standard BSA-directory mode we have:
Giving a total for CA-CA ramp coverage of 7,576 bytes assuming that there is at least one ramp in each BSA (which may not be the case for some tables). If we assume the same carousel time as Speed/Flow (60 s) this requires 1 kbps of bandwidth.
It is worth comparing these numbers to the pure Alert-C coding of 1 x5-byte message per TMC ramp location (11,000x5) requiring 55,000 bytes. We can probably code our ramps service for around 5% of the Alert-C code, even when all ramps in the table have coverage.
All Ramps
From the Michigan State analysis, it can be estimated that 385 CA-CA ramps becomes 2,200, so there is roughly a 5.5× increase in the number of ramps. The other parameters remain the same, giving:
For a total of 18,576 bytes, or 2.5 kbps.
Incidents & Construction
The following table is constructed from a single carousel of the trafficML data feed
Analysis of Free Text Components
The following are typical of the ‘short’ and ‘normal’ construction descriptions:
The short desc adds no information to the Alert-C code (802=long-tem roadworks) and the TMC+extent data (loc=08479,extent=3), so I used the standard desc.
Accident descriptions follow the same pattern.
Again, most of the ‘color’ is in the longer description.
Taking all the of construction events with TMC codes (i.e. those on covered highways), and all of the incident events except class=WEATHER and cleared-accident, we can build the per-table gzipped text files to hold all of the TYPE=desc text fields for a single carousel of all markets:
This would take 22 kbps to send at 30 s intervals, excluding any bits needed to represent the structured form of the event.
Looking at the various forms of the free text for construction, it seems there is a common structure comprising:
Where <routing data> are introduced by “DETOUR” or “ALTERNATE” in the text. If we assume that any description having a “-” in the middle is minimally in the ‘location+event’ style, and that the location data is essentially a duplicate of the Alert-C data, we can strip off anything up to that first “-” in the text. Examples of that approach yielded the following strings:
In exemplary embodiments of the present invention, this exemplifies the level of detail to supply in the text. Removing the first phrase from all construction events brings the compressed string tables down to 33139 bytes, or 8.8 kbps at 30 s. Removing any diversion information then brings that to 7.4 kbps. That results in 14.5 kbps for the compressed tables (at 30 s).
Construction—Structured Data
The protocol for construction includes both a structured component and (now) a compressed free text component. We can map the trafficML fields to the proposed protocol;
The first major difference between the inventive protocol and trafficML is that the trafficML data will contain multiple location references within a single construction event, for example if both sides of the roadway are affected, they will be placed in the same event message.
The second difference is that there is almost always a start and end date given explicitly in the trafficML message. According to Navteq, future events are suppressed from the feed, but we could request that they be supplied, so we should plan to retain start date as an option in the protocol.
An issue is with our LANES and ACTIVE values. Other than the vague descriptions in LANES_BLOCKED both of the values do not appear in tML elements. However they often appear in the free text, for example:
In the last example we would be able to set the ACTIVE.daytime bit in our protocol if we could extract that information from the free text description. These examples are all from table 8, which has very detailed descriptions. Other tables may have less details in the descriptions, and also a different structure to the order of the elements in the text.
Implications
In exemplary embodiments of the present invention, there is a good match between the information content in the trafficML feed (for construction) and our protocol. However there is a very poor match between the two structures. The is especially true of the description field since:
As an example, the 11 Mile Rd description above could be entirely coded in structured form:
Or we could convert END_TIME into ‘4 weeks’ (the sample was taken on 2nd August).
Even the other text descriptions could be cut down for our purposes:
If a provider can structure the construction data in this format, we can get the free text fields down by probably another 30-50% around 5 kpbs at 30 s if we exclude detour information. Adding in 2 kbps for the structured components (1400 events at 40 bits/event at 30 s/carousel) gives 7-8 kpbs for construction data at 30 seconds.
Incidents
The incident data also has a location component and additional text. Removing the location component brings the zip files down to 19718 bytes, or 5.3 kbps at 30 seconds. If we assume a similar 40-bit encoding for an incident for 700 incidents, that's another 1 kpbs again at 30 s.
Bandwidth Estimates
Assuming we can segment the text fields to remove duplicate information, then using a simple per-table zip file plus a structured encoding we have the following bandwidth estimates:
Bandwidth Reduction Options
The following may be implemented to reduce the bandwidth
In exemplary embodiments of the present invention, archives of actual data can be used to estimate the bandwidth required for a predictive service. Assuming perfect knowledge, then the actual data transmitted at (T+τ) is an ideal approximation to the +τ prediction computed at time T.
Delta Coding
Predictive data are delta-coded from a previous state. The first predictive dataset is delta-coded from the most recent Real-Time Speed/Flow data. The second predictive dataset is delta-coded from the first, and so on.
Because we cannot guarantee which ‘current’ dataset is in the receiver, the delta-coding mechanism uses an absolute replacement value, rather than an increment/decrement to the current speed bucket. When the dataset is prepared, it is computed against a particular current dataset, but the resulting pattern will work against any stored values, with improved results. The following table shows how the code operates:
Given two patterns, the delta-difference is then just another pattern which is encoded using exactly the same rules as for ordinary patterns. In the case where the whole of a linear is unchanged between the two patterns, the resulting pattern is zero everywhere along the linear, which is compactly encoded using just ‘00’ in the bitstream, meaning ‘do not change any values in this linear’.
Filtering and Smoothing
The bandwidth required for predictive datasets depends on the choice of filtering and smoothing that is applied to the two original datasets. Since we are delta-coding against a transmitted pattern, the calculation of the delta code must match the pattern that is transmitted, so it must be computed after the pattern has been filtered and smoothed. It makes no sense to filter the delta-coding less aggressively than the original data, but we may choose to filter it more aggressively. The calculations also assume that Predictive data are transmitted at TMC-segment granularity, not subsegment. The proposed algorithm for the delta-coding against the fine-grained real-time values uses a fixed mean-value filter on the real-time data as follows:
At the receiver, when code==0, all 8 sub-segments for that segment are set to: (real_time_sum_of_sub_segments>>3).
The table below gives examples of the encoded sizes for various filtering options. Each cell contains two values, the upper value is the basic delta code, the lower value has an additional mean-value smoothing filter applied after the delta values have been computed.
The values running down the left-hand side are the encoding sizes for the first dataset (taken at 17:00:57). The values running across the top row are the encoding sides for the second dataset (taken at 17:15:23).
More aggressive filtering does not always result in a smaller encoded dataset since this may increase the number of differences between the two datasets, which increases the encoding.
Delta Reduction
There is one other operation that can be performed on the difference data, to reduce encoding size. Looking at the Raw-Raw data (most detailed), the table below shows the actual delta values bucket-by-bucket in the output.
Each column is a speed bucket in the current dataset [1 . . . 14]. Each row is a speed bucked in the predictive dataset [1 . . . 14]. Each cell is the count of delta-coded points for that transition, the diagonal is trivially zero since unchanged values are not delta-coded. The immediate observation from the table is that most of the changes are only a single bucket-value, ±1. If we consider those to be insignificant changes, we can remove those values before delta coding. We might consider two options: the first is only to suppress +1 changes (i.e. places where the predicted speed is one bucket faster than the current speed); the second is to suppress both +1 and −1 values. The former is in keeping with our generally pessimistic view of congestion, while the second will reduce bandwidth, probably with little visible effect.
+1 Removal Only
This requires only 4415 bytes to encode (compared to 6662 for the original dataset).
This requires only 1712 bytes to encode.
Combined Options
The table below shows the dataset sizes for the lower-right-hand corner of the table above.
The ‘None’ column matches the values in the original table, as expected. The two values, upper and lower and without and with additional mean-value smoothing.
These values suggest that each predictive pattern takes approximately 25% of the original pattern to encode. Sending 3 predictive datasets every 90 seconds would then require:
Bits/second, where B is the bandwidth of the Real-Time service with a 60 s carousel time.
Estimated bitrate for predictive data: 11 kbps
Forecast Data
In exemplary embodiments of the present invention, forecast Data extend the range of predictive to the point where the data are approaching historical. For each forecast point we transmit a pattern index that is closest to the desired forecast state, using the perceived error M3 metric. If we send 1 hour forecasts for the next 24 hours, for each BSA in the country we don't need a BSA directory, since the BSA indexes of offsets are fixed. For only 24 values, the burden on the receiver to do change detection is minimal, and we do not need to supply a signature value.
For a total of 18,056 bytes, or 1.2 kbps at a carousel rate of 120 s.
Historic Patterns
Historic Patterns are transmitted as single-byte pattern selectors, according to the M3 metric. Each map is 960 bytes per BSA (24×4×2x5) or 706 kbytes, requiring 2.6 kbps to deliver in 40 minutes.
Base Patterns
Base Patterns are coded in exactly the same way as Real-Time S/F patterns, though we may choose to quantize the data more aggressively (e.g. at the segment rather than sub-segment level).
Navteq Patterns
In exemplary embodiments of the present invention, the analysis of coding and bandwidth for Base Patterns is based on the data to which we currently have access, namely the Navteq ‘traffic pattern’ product. The Navteq traffic pattern dataset is a 68 Mbyte zip archive containing seven pattern datasets, one for each day of the week. Each dataset is a CSV file approximately 136 Mbyte in size, containing 464,476 data records, covering the entire country (approx 1 Gbyte of data).
Each data record is for a single TMC point and direction and contains 96 speed values at 15 minute intervals, as integer miles per hour, for example:
The structure of these data does not match the proposed Apogee model, but all the data are present that we need to build datasets to our own specifications, by extracting individual patterns by table. The first observation is that the history patterns cover all the TMCs in the table, not just those for which we have Apogee flow coverage, so any patterns must first be reduced to our coverage area before encoding.
The next step is to break the patterns down by BSA. This leads to datasets containing 1,500 points (3,000 rows) for BSA 13 (Detroit) and 2,000 points (4,000 rows) for BSA 25 (North Detroit).
We can now treat each of the 672 datasets for each BSA as a pattern, and look for pattern clusters. To do this we first round each speed value down to its bucket value (using 5 mph buckets) and then group the datasets into clusters that are sufficiently similar to each other.
The definition of ‘sufficiently’ similar is:
Note that this definition is not symmetric, we weight errors indicating incorrect free-flow more heavily than errors indicating spurious congestion. This gives the basis for building a cluster model. With only 672 datasets it is possible to enumerate the number of patterns similar to each pattern in the dataset.
For BSA 25 (North Detroit), the dataset representing Tuesday at 22:00 is sufficiently similar to another 171 patterns. This pattern is an obvious contender for inclusion in the master list of patterns we would use. It roughly corresponds to the generic ‘nighttime’ pattern. We can remove that pattern, and all its similar patterns (172 in total), from the dataset, and rebuild the similarity counts, now with only 500 patterns.
Repeating this procedure for all the 672 patterns in the dataset yields the following table:
This implies that 97 patterns are sufficient to represent all the historical data for North Detroit according to the (quite strict) ‘sufficiently-similar’ definition given above. 64 patterns would account for 90% of the historical data.
Repeating the same process for BSA 13 (Detroit) yields similar numbers
So 80 patterns will cover Detroit, and 64 patterns will cover 96% of the historical data.
Looking at one of the smaller BSAs (Flint), the number of patterns is even fewer:
Requiring only 47 patterns to cover the complete history.
Encoding of Patterns
The analysis above uses the ‘raw’ data supplied by Navteq. The patterns that are extracted are exact patterns out of the supplied dataset. Since each pattern is guaranteed to match itself, the process will always terminate (with some 1-element clusters). In reality we would want to apply our filtering and smoothing algorithms to the patterns to prepare them for transmission. However, applying the strict similarity test between the smoothed patterns and the original datasets does not terminate, since spike removal causes a pattern no longer to match itself (comparing smoothed against original).
Our approach will require extracting the exact patterns using the algorithm (or a similar one) described above, then smoothing the resulting pattern set, followed by a second phase to redistribute exact patterns into the new clusters.
Bandwidth
If we quantize at the segment level, the pattern sizes will be similar to those in the coding samples. From the trafficML table, a complete pattern will be somewhere between 150 kbytes and 300 kbytes depending on how heavily it is smoothed. Taking the lower value, we can encode 16 patterns into a 2.4 Mbyte dataset, which is a good number for RFD transmission (that's 600 RFD blocks). Assuming the usual +10 overhead and feeding those numbers into the RFD calculator, we require 9 kbps to deliver that update in 40 minutes. This assumes that we only update 16 patterns at a time.
Use of Patterns for History
As supplied, the Navteq dataset is a 7-day model, unlike the proposed Apogee model (Mon-Thu, Fri, Sat, Sun, Holiday). Comparing the two models, the Navteq dataset does not have data for explicit ‘Holidays’ only for generic weekdays. Also the Navteq dataset does not distinguish seasonal data. From the cluster analysis, the datasets align more through the day, rather than across the days. For example there is an identifiable cluster that represents “Thursday lunchtime”, but it not sufficiently close to “Monday lunchtime” that they fall into the same cluster.
If we wish to maintain the Mon-Thu model we need to generate suitable patterns that run across the days, then apply the clustering algorithms to those datasets. Without knowing if Navteq has retained the original input data with timestamps, we cannot determine f we can map their temporal model into ours.
Pattern Evolution
The analysis above has determined that the Navteq pattern dataset could be used a basis for the Apogee Forecast and Historical service elements. We can convert their patterns into at most 128 patterns for each BSA, leaving room for more refined data (e.g, Summer/Winter or holidays). However we may also wish to specify that our chosen provider start to build a more accurate dataset over the next 2 years to our specifications, closer the Apogee architecture. We can choose to focus on high-probe-density roads and build an update that has improved parametric separation on FC1-2 roadways while using the same base data for lower-class roads.
Michigan BSAs
The Michigan (table 8) BSAs cover a region of −87.325980, 40.989530 to −82.424480, 46.670640. It includes 32 ‘superlinears’, i.e. linears that are the parent of other linears, and have no points as immediate children. The remaining linears and points are divided as follows.
The count of non superlinears increases from 960 without BSA splitting to 1197 after linears are split at BSA boundaries.
Bandwidth Estimates for trafficML
‘Raw’ column simply encodes the full dataset at 5 mph granularity. L- and H- indicate removal of Low and High spikes (only). -S indicates mean-value smoothing. LS and HS are mean-value smoothed after removal of Low and High spikes, respectively.
These values are for the main roadbed only, not including the HOV lanes.
BSA Coding
For the full-table mode at 16:00 and 18:00 on the sampled day we have:
‘Same’ and ‘Mixed’ are the count of linears with the same bucket, or mixed buckets. ‘Mixed Msgs’ are the number of ‘01’ and ‘10’ messes required to encode the ‘Mixed’ linears. Each ‘Same’ linear takes 9 bits to code, and each ‘Mixed’ linear takes 16 bits/message+2 bits per linear.
We can compare these values with the per-BSA coding as follows:
Giving 979 bytes at 16:00 and 867 bytes at 18:00 as reported in the previous table.
The following values are from 3-4 days of the full trafficML research feed from Navteq.
Total Number of distinct Alert-C codes: 110
Part III—Exemplary Software Development Kit
Introduction
This part describes an exemplary interface to the Apogee Traffic service, the functionality, implementation and architecture of which are provided in Parts I and II, above. As above, all references in what follows to “uses” “should use” “is” “are” or the like, are illustrative and merely exemplary, and not limiting, referring only to one or more exemplary embodiments, but certainly not defining how the invention may be implemented. Additionally, the same exemplary, and not at all limiting, character applies all variable names, function names, data structure names, etc., which appear in this Part III with an SXM designator, such as, for example: “SXM ——————” or “SXMApogee ——————.” Moreover, any reference to a particular software library, or to a particular messaging protocol, anywhere in Part I, Part II or Part III of this Specification is exemplary and illustrative only, and not intended to be limiting in any way.
Resources
In one embodiment, for example, the SXM-supplied locations file is compiled into a binary form and must be present in the read-only portion of the file storage system. The path to this file must be returned by a call to makepath with parameters:
When mitgrating to a different version of SXe SDK, the “locations” baseline must be replaced with the recompiled baseline databases using the skdfiles utility. The baseline databases are not always compatible between releases and must be replaced when migrating to a different version of SXe.
The historical maps are pattern data are updatable through a rapid file delivery application or service, such as Sirius XM Rapid File Delivery, or RFD, described above, and must be located in the updatable portion of the filing system.
The TrafficPlus (Apogee Traffic) Module
The SXe TrafficPlus (Apogee Traffic) SDK decodes the TMC broadcasted information using a “locations” database to assist in decoding and provides traffic information to the application through the APIs. Even though a TMC segment is defined as the path between two TMC points, the actual roadbed is unlikely to be a straight line between those two points. In order to draw the roadbed, indicate congestion, and place incident markers, the TMC segment must be converted to a set of map links. A map link is a straight-line drawn between two points, at sufficient resolution that the map follows the actual road topology for a map at a given zoom level.
Links are supplied from a map database, which must be purchased from a map vendor. SiriusXM does not require a specific map-link database, nor does it require the map be obtained from a particular vendor. The Apogee protocol is vendor- and database-agnostic. It is the responsibility of the application developer to obtain both a map database and the TMC consortium traffic tables and to integrate them into their product.
The application developer should be aware the TrafficPlus service uses a mutex to serialize most APIs calls and care should be exercised to insure a deadlock condition does not occur. The sxr_apogee_status API is not serialized by the mutex and therefore will never block. See “Thread Safety” section in the core design guide SX-9845-0339 for additional information.
Status Return Code
The usual way in which errors are reported is through the return code on most interface calls. Except where noted, SXM_E_OK usually indicates a successful call or an error otherwise. In some cases this may simply mean the operation was ‘accepted’ it does not imply that the requested action will be performed successfully.
It is convenient to consider API return codes as falling into three classes, for any given call:
An example of a Normal return is ‘No more items in list’ for a data extraction. A Weak error indicates that the API call is not going to work, but other calls may, for example starting a service when the service is already running. A Strong error indicates that the whole of the service is non-operational. A possible Strong error could be: “Out of Memory” when starting the service. Other services may continue to operate, but the requested service is unable to initialize, and will not operate correctly (or at all).
The Module Interface
The start routine starts the Apogee traffic service,
The module-level callback is described in the “Error Detection and Reporting” section of the SX-9845-0340 Introduction Design Guide. The following errors may be indicated on the callback interface
sxm_apogee_status
The status routine updates the data service status structure SXMStatus with the current state and subscription status. A return code of SXM_E_OK indicates the status structure SXMStatus has been updated, otherwise it has not.
The SXMStatus structure can be examined to determine the service state and subscription level for the service.
Service States are:
Service subscription levels are:
sxm_apogee_stop
The stop routine terminates the service
The routine will block if there is an extraction currently in progress, and will fail if it is called from within a notification callback routine.
An unrecoverable SXe service event has occurred when calling the sxm_apogee_stop function with one of the error codes of SXM_E_STATE or SXM_E FAULT are returned with that status.service being SXM_SERVICE_OK. In this event, the application developer shall reset the SXe system so that the service(s) and the supporting framework can be reinitialized to a pristine condition
The Request Interface
Exemplary SXMApogeeRequest Structure
Apogee collection requests operate on a geographic area defined as a list of table and BSA pairs. These are passed across the API using the SXMApogeeRequest structure
Collection requests are for a specific type of Apogee data. Multiple types may be combined over a single collection area by OR'ing the values together from the following list:
Two combination fields are also useful:
sxm_apogee-request
The request routine submits a request and starts collecting its data. The Traffic Plus allows for a maximum of 8 concurrent requests at a time.
data_notify Callback
The notification routine is called from within the SDK whenever data in a BSA is changed or refreshed:
The notification routine may be called many for each collection request, and many times for each BSA, since the different components of the service are updated at different rates. It is strongly recommended that the notification routine does as little processing as possible, just noting the change of state, and leaving the extraction and display to the main application
sxm_apogee-modify
The modify routine can be used to change the area or collection types of an active request.
sxm-apogee-remove
The difference between modifying a request and removing then resubmitting the request is that any data common to the old and new requests will be retained by modify, but deleted if the request is removed.
The remove routine deletes a request. Once a request is deleted, the handle for that request must not be used again.
Removing a request will stop the collection of any data not otherwise required by other requests, and remove any stored data collected as part of the request.
The Extraction Interface
The notification routine described above only informs the application that data have changed, it does not process the data in any way.
Service Objects
The extraction interface allows the application to retrieve ServiceObjects contained the decoded protocol information. Three ServiceObjects are offered through this interface,
The FlowVector object contains the speed and flow data for a single linear in a BSA
The first row of speed values represents the positive direction in RDS/Alert-C and runs from tmc_start to timc_end, the second row represents the negative direction and runs from tinc_end to tmc_start. All four arrays are in units of ⅛ TMC segment.
The valid value is the maximum of the two directions. For a flow vector that terminates in both directions, valid would be 8×(number_of_tmc_points−1) In the case where the flow vector continues into another vector in one or both the other directions, valid would be 8×number_of_tmc_points. The actual number of points is determined by the topology in the TMC tables.
The RampVector object contains all the Ramp flow values for a single BSA, either the TMC-defined ramps or the SXM-defined ramps.
Each byte contains the congestion level for a single ramp, in BSA index order.
The CIMessage object contains either a Construction Message or an Incident
Routines
The begin routine starts an extraction, and locks the data against updates by the SDK.
Since only one type of data can be extracted at a time, the type field should be only a single bit from the SXM_APOGEE_REQ types, and it must match one of the bits set in the original request. For forecast and historical data, the index value specifies which particular forecast point, or historical data value, is required. For ramps it selects either the TMC-coded ramps (index=0), or the SXM-coded ramps (index=1). The bsaref value is the value of an element in the bsaref array on the original request.
For flow requests, c1 is set to the number of items available in the extraction and c2 is set to the number of lane types available for that request type.
Unlike the Alert-C protocol delivered over RDS/TMC, the full data for any type are available during an extraction. Therefore the application does not need to maintain state between extractions, though it may choose so to do to reduce processing (for example when looking at only a few segments in a linear during a route or travel-time calculation).
The ServiceObjects are extracted using one of the following three calls,
sxm_apogee_extract_flow
All roadbed (non-ramp) flow types (current, predictive, forecast, historical, by-lane) are extracted into the same data structure, the FlowVector. The parameters on the call determine which particular type is used.
To support efficient processing, the following constraints are placed on the sequence of calls to
sxm_apogee_extract_flow:
The changed value is set to zero if the contents of the FlowVector are the same as the last time it was extracted, or one if something in the FlowVector has changed. In both cases the FlowVector values are filled in. The application can use the changed value to skip processing for that index, or may need to process it anyway.
sxm_apogee_extract_ramp
Ramp flow values are extracted into a RampVector structure
There are no restrictions on the order in which the two type values can be extracted.
sxm_apogee_extract_ci
Construction and Incident messages share a common format, and are extracted from a single interface.
Unlike flow vectors, although messages have a unique reference numbers, there is no guarantee that the messages will be returned in any specific order, or that a particular reference number is present in the collection. As a result, the extraction interface behaves more like an iterator, where subsequent calls simply return the next available message. The sequence number om the event acts as the change marker, but it is the responsibility of the application to track the most-recently-extracted sequence number to implement any change-detection scheme.
sxm_apogee_end
The end routine terminates the extraction, and unlocks the data for update
Apogee Utility Functions
Utility functions help create requests, and allow the application to determine which products are available.
Language Options
The Apogee extraction interface for Construction and Incidents will return the event descriptive text in the user's preferred language, if available, as determined by the SDK-level “lang” option.
Building Filters
The Apogee collection request is a list of BSAs, using the standard TMC table numbers and the BSA
It is usually easier for the application to determine a collection area based on a point location and a distance. The sxm_mbr_about routine can turn a point and distance into a map bounding rectangle. The rectangle can then be turned into the list of BSA references which will cover that area.
The resulting request structure is then suitable for passing directly to sxm_apogee_request along with the collection type.
sxm_apogee_add_linears
Extraction filters are handled entirely within the application, but the filter can be constructed by the SDK. The application can build a filter for a single BSA reference given a map bounding rectangle using sxm_apogee_add_linears. The result is an array of bits where each bit is one if that linear intersects the map rectangle, and zero otherwise.
sxm_apogee_add_all_linears
If linear filtering is going to be applied to all the BSAs in a collection, a set of filters can be built from the original collection request using sxm_apogee_add_all_linears. The returned bitmaps are in the same order as the BSA references in the collection request.
sxm_apogee_add_ramps
The same filter structure can also be used for ramp flow vectors. In this case the bit is one if the ramp at that index lies within the map rectangle, and zero otherwise.
sxm_apogee_add_all_ramps
The filter can be built on a per-BSA basis, or for the whole collection, using sxm_apogee_add_all_ramps.
Note that to filter all possible data, three separate filter banks are required, one for the main roadbeds, one for TMC-coded ramps and one for SXM-coded ramps. A single filter is 204 bytes long, and a 64-BSA collection filter is 13,060 bytes (so around 40 kbytes is required to support full 3-way filtering).
Product Availability
Three aspects of the service are not fixed by the protocol, and may vary from BSA to BSA over a collection. If a REQ_FLOW extraction indicates that more than one lane type is available, the lane types for each index can be retrieved using sxm_apogee_get lanes:
The number of valid entries in the ltypes array is the c2 value returned by sxm_apogee_begin. ltype[0] will always be 0, indicating the main roadbed. The other lane types are defined in the Apogee Protocol Specification.
sxm_apogee_get_predictive
If predictive datasets are being collected, the time ranges of the currently-available datasets can be retrieved using the sxm_apogee_get_predictive call.
The ptypes values are the starting time range, in minutes, for which that prediction index is valid.
If forecast datasets are being collected, the time ranges of the currently-available datasets can be retrieved using the sxm_apogee_get_forecast call.
The ftypes values are the starting time range, in minutes, for which that forecast is available.
The Development Interface
The debug interface allows the application to change the logging level on the apogee module once it has been initialized.
sxm_apogee_set_debug
sxm apogee_get_debug
The purpose of this section is to show how the various calls fit together to provide a full service to the application. This is not a complete application ready to drop into an automotive system and provide a full Apogee traffic service. The other aspect that it is difficult to capture in example code is appropriate error handling, Application techniques for handling errors may be quite different during initial development,
pre-production validation and final production-level builds, so the generic directive of ‘handle error here’
serves as an indication that error processing will be required in that code path.
Appendix A contains the complete listing of the code fragments explained here, to show how it all fits together.
The example illustrates the following operations:
The following operations are not illustrated, and must be developed by the application
The main routine initializes the SDK with the three configuration routines, then starts the audio service and the Apogee Traffic service.
It then sets up a request to collect data for an area (this assumes that the user has selected a map region, or the system GPS input has determined an area over which to start collecting.
In the example, the main processing loop is very simple, it assumes that the application goes away and does some processing and at some point returns to check for any changes to the traffic data. In a larger application, this call would only be made when the system was displaying traffic data, or calculating routes and travel times.
Configuration Callbacks
These routines are identical to the test routines used in the SDK CLI, as described herein.
Module-Level Callbacks
These two routines request the status information from the appropriate module. The most likely states that would need to be handled are:
More severe messages, such as “No Apogee Location Table” would indicate an incorrectly installed system (and a visit to the dealership).
Requesting an Apogee Data Collection
The routine builds a collection request for the area from 84.00° W 41.75° N to 82.75° W 42.75° N which contains the center of Detroit and extends for approximately 70 miles (35 miles in each direction from the center point). A real application would be using values from a GPS system to determine the collection area. The map area is then converted to a list of Tables and BSAs.
The strategy for handling notifications is to accumulate changes for later processing. The changed array is used to hold the change markers for each BSA in the collection, and this is initially set to zero.
The routine the submits a collection request for all of the realtime data components, passing in the address of the collection-change routine and receiving the response handle (in the response variable).
To illustrate linear filtering, the routine then constructs a separate extraction map rectangle covering the area from 83.25°W 42.25°N to 83.00°W 42.5°N which includes the center of Detroit. Again, in a real application, these values would be determined from a map display and zoom level. The map MBR is then converted into an array of bitmaps, one for each BSA in the collection, using the response handle to match up the BSA references between the collection request and the filter array.
Collection Change Notification
This routine is called by the Apogee SDK to inform that application that data for a particular BSA in a collection request has changed or been refreshed (without change). j is the index in the array of BSA references in the original collection request and types is a bitmask of which collection types are being reported on.
The routine merges the change indications with any unprocessed changes (and ignores the refreshed data), but otherwise does not attempt to process the changes in any way.
Application Change Processing
When the application is ready to process Apogee traffic changes, it calls this routine, which examines the change markers for each of the BSAs in the collection area (as set in request.bsac). Unlike the collection request, here each individual collection type must be examined individually, and processed according to its own type.
Once any changes have been processed, the changed markers for that BSA are cleared. Strictly, this approach to setting and clearing change markers is not thread-safe, since a collection update callback could set a change flag while the routine is scanning and processing the flags. However, this is not a real problem since the change may already have been processed, and if it was missed it will be signaled on the next round, That being said, it would be only a small extension to copy and reset the flags under a mutex, and add a mutex around the update in the indication apogee routine.
Linear Filtering and Extraction
The flow extraction routine demonstrates the use of the filter bitfield to narrow down the list of Flow Vectors that needs to be extracted. The routine first locks the extraction data, and collects the number of vectors available (fin) and the number of lane types in this BSA (lane). The example code only processes the main roadbed (zero as the second parameter in the extraction call).
The filter code uses a macro defined as:
Once all the flow vectors have been examined, the routine unlocks the data for further updates.
Ramp Flow Extraction
The routine to process ramps needs to handle both TMC-coded ramps, and SXM-coded ramps. Unlike linears, all the ramp flow values for a BSA of a given type can be extracted in a single call. The routine uses a statically-allocated rv structure to extract first the TMC-coded ramps, then the SXM-coded ramps.
This example could also be extended to support MBR filtering of ramps by creating a pair of ramp filters
(one for each type) and using the same BITTST code used above for linears.
Construction and Incident Extraction
The logic for extracting construction and incident messages is identical for both message types, the only difference being the type request when the extraction is started. The routines loop over all the messages, extracting them one-at-a-time into a statically-allocated ci structure, until the SDK indicates there are no more messages left for that BSA.
The CLI commands for Apogee
When running the CLI in pure-SDK mode (i.e. not under control of the SMS CLI) the:
The user should refer to the “The SDK CLI” section of the “SX-9845-0340 Introduction Design Guide” for setting up the necessary files and how to run the SDK data services CLI application.
Demonstration
The apogee traffic system may be easily verified using the built-in demonstration command
The options are as follows
Run the default demonstration around Philadelphia:
Process data in the Los Angeles MBR for 60 minutes processing change every 31 seconds with the debug level 0x0ff2f007:
The following commands control the module as a whole:
Collection Requests are built up using a sequence of CLI operations
There are two types of filter. A single BSA filter will filter linears for a BSA while a full filter will filter for all linears in the collection request.
Data are extracted into Apogee Service Objects, which must first be allocated by the CLI.
These objects can then be in the extractions
The extracted data can be displayed using the show command
The output depends on the type of the variable:
The following example script is similar to the Philadelphia demonstration, but showing how the individual commands can be joined into a set of test cases. The user should refer to the “Running the CLI” section of “SX-9845-0340 Introduction Design Guide” for setting up the necessary files and how to run the SDK data services CLI application.
Apogee Sample Code Listing
The Apogee locations file may be built and analyzed using the sdkfiles utility.
The builder takes as input (-i) a CSV file containing one line for each SiriusXM locations table in the service.
The first column is the table number, the second column is the number of BSAs in the table, and the third column is the path to the SiriusXM location file. The format of the location file is specified in the Protocol Document,
The output is the binary locations file, which has the following structure. It is organized as a transaction file (even though the file is read-only). The root block of the file contains an array of Table entries, one per TMC table in the service.
Note that the stored values are in fixpoint (integer) format, so the same locations database can be used whether or not the application builds the SDK with native floating-point support.
The blocks addressed at offset contain an array of count BSA entries.
The linear and ramp blocks both contain arrays of Linear entries
The resulting file can be analyzed using the -t option of sdkfiles:
The output first reports the tfile header integrity:
It then formats all the table BSA and linear data:
Exemplary Systems
In exemplary embodiments of the present invention, any suitable programming language may be used to implement the routines of particular embodiments of the present invention including C, C++, Java, JavaScript, Python, Ruby, CoffeeScript, assembly language, etc. Different programming techniques may be employed such as procedural or object oriented. The routines may execute on a single processing device or multiple processors. Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different particular embodiments. In some particular embodiments, multiple steps shown as sequential in this specification may be performed at the same time
Particular embodiments may be implemented in a computer-readable storage device or non-transitory computer readable medium for use by or in connection with the instruction execution system, apparatus, system, or device. This may be true in either a transmission end device (e.g., pre-processor, aggregator, etc.) or a receiver, for example. Particular embodiments may be implemented in the form of control logic in software or hardware or a combination of both. The control logic, when executed by one or more processors, may be operable to perform that which is described in particular embodiments.
Particular embodiments may be implemented by using one or more programmed general purpose digital computers, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nanoengineered systems, components and mechanisms may be used. In general, the functions of particular embodiments may be achieved by any means as is known in the art. Distributed, networked systems, components, and/or circuits may be used. Communication, or transfer, of data may be wired, wireless, or by any other means.
It will also be appreciated that one or more of the elements depicted in the drawings/figures may also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application. It is also within the spirit and scope to implement a program or code that may be stored in a machine-readable medium, such as a storage device, to permit a computer to perform any of the methods described above.
As used in the description herein and throughout the claims that follow, “a” “an”, and “the” includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
While there have been described methods for providing a traffic collection, aggregation and transmission system, it is to be understood that many changes may be made therein without departing from the spirit and scope of the invention. Insubstantial changes from the claimed subject matter as viewed by a person with ordinary skill in the art, no known or later devised, are expressly contemplated as being equivalently within the scope of the claims. Therefore, obvious substitutions now or later known to one with ordinary skill in the art are defined to be within the scope of the defined elements. The described embodiments of the invention are presented for the purpose of illustration and not of limitation.
This application is a continuation-in-part of co-pending International Application No. PCT/US2014/029221, designating the United States, with an international filing date of Mar. 14, 2014, and also claims the benefit of U.S. Provisional Application No. 61/785,663 filed on Mar. 14, 2013, to which benefit and priority were claimed in PCT/US2014/029221, the disclosures of each which are incorporated herein by reference in their entireties.
| Number | Name | Date | Kind |
|---|---|---|---|
| 20030100990 | Clapper | May 2003 | A1 |
| 20080069032 | Liu | Mar 2008 | A1 |
| 20120072096 | Chapman | Mar 2012 | A1 |
| 20140278052 | Slavin | Sep 2014 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20210264776 A1 | Aug 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61785663 | Mar 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14852608 | Sep 2015 | US |
| Child | 17026608 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/US2014/029221 | Mar 2014 | WO |
| Child | 14852608 | US |
