RSS
Throughout this evolution, the technical communities have engaged in standards development in an attempt to create uniformity among the various components that comprise a telematics system. Unfortunately, the length of the telematics road has meant that several generations of disruptive technologies have also become available to developers, and while technology shouldn't necessarily affect a well-crafted standard, the reality is that all standards are tainted by implementation-related elements to some degree, and the more disruptive the technology, the more likely it is to render standards inadequate, if not obsolete.
Discounting the tendency for technical people to develop standards simply because they can, the need for standards is driven by two primary forces: economics and interoperability.
On the economic side, once a new technology paradigm evolves past the research phase and real products surface, the desire to reduce costs invariably manifests itself. There is no economic advantage in creating non-differentiating products, so those products that can be made standard are typically standardised and they embark on the road to becoming commodities, accompanied by increasingly lower costs.
On the technical side, system elements that depend on each other (those that must interoperate) must follow well-established interface requirements. While these interfaces can be proprietary and therefore not exposed for some systems (the internal workings of a vehicle databus are an example), when these elements are procured and managed by different entities the need for well-defined interfaces becomes significant. This is especially true in the case of systems like telematics where a wide variety of independent sources and users of data exist, all driven by different business and technical challenges. It does no-one any good to require a traffic signal (or a traffic information provider, for that matter) to send messages in dozens of formats over dozens of air-link protocols simply because there are dozens of different terminal makers each with their own ideas on what approach is best. Similarly, it does no-one any good to require a vehicle system to support multiple different types of traffic signal warning system simply because several different signal-makers have their own ideas on how such a system could work. Fortunately, this particular example has been the subject of relatively intense coordination. Other areas in telematics are non-uniform and this will limit the growth of the field.
Generally, these heterogeneous approaches will quickly collapse as the market scales. As a result, telematics has a particularly strong need for standards. However, it may well be that the scope of telematics standards has been too narrow, and too deep, and as a result it has missed important areas that can benefit from standardisation (and which will in turn benefit the industry); it may be that it has delved too deeply into technical implementations that may become brittle as technology evolves.
324 US Department of Transportation (USDOT) and the VII Consortium successfully demonstrated communication between cars and between the roadside and cars using these standards. This system also included a unique 'back end' system that aggregated data collected from vehicles on the road and, using a web services approach, allowed data users to subscribe to various data 'topics' and thereby receive a near real-time flow of specified data parameters from the cars in the field. As elegant as this system is, and as well as it worked, it also illuminated a substantial hole in the array of telematics standards. In the POC the interfaces and formats necessary to request and decode information from the system were entirely proprietary, and necessarily so, because there are no standards for these interfaces.
Similarly, recent generalisations of the IntelliDrivesm concept have suggested using a variety of different data links (DSRC, cellular, WiMax and so on). Figure 1 illustrates a fully heterogeneous data collection and distribution system; a variety of different data source devices use a variety of different communications links to convey data in a variety of different formats to the system. The system then aggregates this data and distributes it again through a variety of different communications links and in (presumably) the original formats used to collect it. The applications used for the collection and distribution can similarly vary. Such a system may well work but it is hamstrung by the need for numerous custom interfaces to reorganise the data for each user's particular applications. When one considers that the system is also bi-directional, the difficulty of accommodating a wide variety of links, formats and applications quickly escalates beyond feasibility.
Figure 2 illustrates the opposite extreme where both the collection and distribution sides of the system are limited to a single standard implementation (DSRC and J2735 on the collection side, and a single proprietary interface on the distribution side). This is the approach used for the VII Proof of Concept. While using a proprietary back-end implementation was expedient and cost-sensitive for demonstration purposes in the POC, it is clear that a full-scale implementation using this approach would limit data users (road authorities, state and local DOTs and other service providers) to an inflexible suite of implementation choices; it is also unclear how such an implementation could evolve as technologies change (which was one of the motivations to suggest a more flexible approach in the IntelliDrive community).
Identifying opportunities and gaps
A number of entities, government agencies, standards and specification organisations are now exploring the standards landscape to determine what exists, where the gaps are, and what boundary overlaps will occur when communication, vehicle and information technology environments integrate. If standards are developed for these information needs and data delivery formats, the users (state, local and federal agencies and various other service providers) can specify these standards for their system implementations and thereby either obtain information from any number of information providers or change providers at will. This is a much more robust approach than a proprietary system where the users would then be locked into the technology of whomever had implemented the system, and much more easily managed than a balkanised approach where the user must support a cornucopia of formats and interfaces. In the rigid approach, the stakeholders are so constrained that the system cannot adapt to new ideas or new technologies and users will become dissatisfied. In the balkanised approach there is so little definition that the system can never reach critical mass and users will lose patience and abandon it. Either approach does not bode well for a long-term robust solution.
On the mobile side it is critical to limit the link choices to those that actually provide usable quality of service and are appropriate to the mobile environment. One can't imagine, for example, using satellite links to deliver school zone warnings for every road in the country, nor can one imagine using cellular links to provide traffic signal information. However, it may be less important to proscribe specific data formats. Data from vehicles comes in a wide array of forms. For example, speed might be reported from one vehicle in metres per second, another might report it as miles per hour; yet another might report it as pulses per second. One approach to this might be to demand that all data reported be converted at its source into common units and scale factors (this is the J2735 approach), however organising every device-maker to conform to a single standard may be challenging, and even reaching agreement on what such a uniform standard might be has proven to be a long and involved process. An alternative might be to define a standard format for distributed data (such as the formats identified in SAE J2735) and convert the data centrally as it is collected. This simplifies the process from the device-makers' perspective, and it is certainly faster to implement, but it also then requires a well-defined description of how each device-maker chooses to report the various data types. Regardless of how it is implemented, clearly the data must be describable using some universally understood means.
Similarly, a standard set of service descriptions oriented toward the types of data and the types of service operations expected to be generated by the IntelliDrive system could be used on the back side to simplify the task of accessing data collected by the system, without overly limiting the user implementations. This could include uniform data types, names, qualifiers and operations related to the services, as well as standards means for geographic and/or roadway referencing. This approach could also use a common registry approach for dissemination of extensions and updates.
The result of this effort would be that any conforming application could request data from any conforming provider without requiring any specialised proprietary interfaces.
As we draw closer to implementing some from of nationwide mobile data collection and distribution system, the need for standardising not only the way it is collected but also the way it is distributed is becoming increasingly important. How the industry chooses to address this will determine the growth rate of the users of the system, and this will ultimately govern how quickly and effectively the entire IntelliDrive enterprise can reach critical mass.RSS
Scott Andrews and Scott McCormick take a look at how standards development for the telematics environment needs itself to evolve in order to stay abreast of technological advances.
While the road has been somewhat arduous, telematics has evolved from a research activity to a resource for fleet operators, consumers and road management authorities.Throughout this evolution, the technical communities have engaged in standards development in an attempt to create uniformity among the various components that comprise a telematics system. Unfortunately, the length of the telematics road has meant that several generations of disruptive technologies have also become available to developers, and while technology shouldn't necessarily affect a well-crafted standard, the reality is that all standards are tainted by implementation-related elements to some degree, and the more disruptive the technology, the more likely it is to render standards inadequate, if not obsolete.
Discounting the tendency for technical people to develop standards simply because they can, the need for standards is driven by two primary forces: economics and interoperability.
On the economic side, once a new technology paradigm evolves past the research phase and real products surface, the desire to reduce costs invariably manifests itself. There is no economic advantage in creating non-differentiating products, so those products that can be made standard are typically standardised and they embark on the road to becoming commodities, accompanied by increasingly lower costs.
On the technical side, system elements that depend on each other (those that must interoperate) must follow well-established interface requirements. While these interfaces can be proprietary and therefore not exposed for some systems (the internal workings of a vehicle databus are an example), when these elements are procured and managed by different entities the need for well-defined interfaces becomes significant. This is especially true in the case of systems like telematics where a wide variety of independent sources and users of data exist, all driven by different business and technical challenges. It does no-one any good to require a traffic signal (or a traffic information provider, for that matter) to send messages in dozens of formats over dozens of air-link protocols simply because there are dozens of different terminal makers each with their own ideas on what approach is best. Similarly, it does no-one any good to require a vehicle system to support multiple different types of traffic signal warning system simply because several different signal-makers have their own ideas on how such a system could work. Fortunately, this particular example has been the subject of relatively intense coordination. Other areas in telematics are non-uniform and this will limit the growth of the field.
Generally, these heterogeneous approaches will quickly collapse as the market scales. As a result, telematics has a particularly strong need for standards. However, it may well be that the scope of telematics standards has been too narrow, and too deep, and as a result it has missed important areas that can benefit from standardisation (and which will in turn benefit the industry); it may be that it has delved too deeply into technical implementations that may become brittle as technology evolves.
Going too far?
An example is the development of Dedicated Short-Range Communications (DSRC) which include air-link protocol (IEEE 802.11p), data communications protocol (IEEE 1609) and data message standards (SAE J2735). These standards are critical to ensuring that roadside equipment and mobile terminals can exchange information, and the utility of these standards has been demonstrated in several research programmes. The recent VII Proof of Concept (POC) programme undertaken by theSimilarly, recent generalisations of the IntelliDrivesm concept have suggested using a variety of different data links (DSRC, cellular, WiMax and so on). Figure 1 illustrates a fully heterogeneous data collection and distribution system; a variety of different data source devices use a variety of different communications links to convey data in a variety of different formats to the system. The system then aggregates this data and distributes it again through a variety of different communications links and in (presumably) the original formats used to collect it. The applications used for the collection and distribution can similarly vary. Such a system may well work but it is hamstrung by the need for numerous custom interfaces to reorganise the data for each user's particular applications. When one considers that the system is also bi-directional, the difficulty of accommodating a wide variety of links, formats and applications quickly escalates beyond feasibility.
Figure 2 illustrates the opposite extreme where both the collection and distribution sides of the system are limited to a single standard implementation (DSRC and J2735 on the collection side, and a single proprietary interface on the distribution side). This is the approach used for the VII Proof of Concept. While using a proprietary back-end implementation was expedient and cost-sensitive for demonstration purposes in the POC, it is clear that a full-scale implementation using this approach would limit data users (road authorities, state and local DOTs and other service providers) to an inflexible suite of implementation choices; it is also unclear how such an implementation could evolve as technologies change (which was one of the motivations to suggest a more flexible approach in the IntelliDrive community).
Identifying opportunities and gaps
A number of entities, government agencies, standards and specification organisations are now exploring the standards landscape to determine what exists, where the gaps are, and what boundary overlaps will occur when communication, vehicle and information technology environments integrate. If standards are developed for these information needs and data delivery formats, the users (state, local and federal agencies and various other service providers) can specify these standards for their system implementations and thereby either obtain information from any number of information providers or change providers at will. This is a much more robust approach than a proprietary system where the users would then be locked into the technology of whomever had implemented the system, and much more easily managed than a balkanised approach where the user must support a cornucopia of formats and interfaces. In the rigid approach, the stakeholders are so constrained that the system cannot adapt to new ideas or new technologies and users will become dissatisfied. In the balkanised approach there is so little definition that the system can never reach critical mass and users will lose patience and abandon it. Either approach does not bode well for a long-term robust solution.A case for review
So what is the right answer? While there are a few data format standards out there (ASTM and TIA, for instance), it seems that the existing body of standards should be reviewed in the context of modern service-oriented architectures and the sorts of information and information services that could be created as a product of IntelliDrive. These approaches are designed to adapt dynamically to evolving services and technologies. However, they also require sufficiently complete and standardised definitions that adaptive software systems can make use of them.On the mobile side it is critical to limit the link choices to those that actually provide usable quality of service and are appropriate to the mobile environment. One can't imagine, for example, using satellite links to deliver school zone warnings for every road in the country, nor can one imagine using cellular links to provide traffic signal information. However, it may be less important to proscribe specific data formats. Data from vehicles comes in a wide array of forms. For example, speed might be reported from one vehicle in metres per second, another might report it as miles per hour; yet another might report it as pulses per second. One approach to this might be to demand that all data reported be converted at its source into common units and scale factors (this is the J2735 approach), however organising every device-maker to conform to a single standard may be challenging, and even reaching agreement on what such a uniform standard might be has proven to be a long and involved process. An alternative might be to define a standard format for distributed data (such as the formats identified in SAE J2735) and convert the data centrally as it is collected. This simplifies the process from the device-makers' perspective, and it is certainly faster to implement, but it also then requires a well-defined description of how each device-maker chooses to report the various data types. Regardless of how it is implemented, clearly the data must be describable using some universally understood means.
Similarly, a standard set of service descriptions oriented toward the types of data and the types of service operations expected to be generated by the IntelliDrive system could be used on the back side to simplify the task of accessing data collected by the system, without overly limiting the user implementations. This could include uniform data types, names, qualifiers and operations related to the services, as well as standards means for geographic and/or roadway referencing. This approach could also use a common registry approach for dissemination of extensions and updates.
The result of this effort would be that any conforming application could request data from any conforming provider without requiring any specialised proprietary interfaces.
As we draw closer to implementing some from of nationwide mobile data collection and distribution system, the need for standardising not only the way it is collected but also the way it is distributed is becoming increasingly important. How the industry chooses to address this will determine the growth rate of the users of the system, and this will ultimately govern how quickly and effectively the entire IntelliDrive enterprise can reach critical mass.RSS
