WO2012174524A2 - Systèmes et procédés de fourniture de services télématiques à des véhicules - Google Patents

Systèmes et procédés de fourniture de services télématiques à des véhicules Download PDF

Info

Publication number
WO2012174524A2
WO2012174524A2 PCT/US2012/042941 US2012042941W WO2012174524A2 WO 2012174524 A2 WO2012174524 A2 WO 2012174524A2 US 2012042941 W US2012042941 W US 2012042941W WO 2012174524 A2 WO2012174524 A2 WO 2012174524A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
telematics system
telematics
components
received
Prior art date
Application number
PCT/US2012/042941
Other languages
English (en)
Other versions
WO2012174524A3 (fr
Inventor
Sammy Halimi
Craig George Kenneth COPLAND
James Bonasera
Steven Deeb
Bharath Yanamula
Karthuapandian R. SANKER
Original Assignee
Agero Connected Services, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/524,588 external-priority patent/US20120253551A1/en
Application filed by Agero Connected Services, Inc. filed Critical Agero Connected Services, Inc.
Priority to CA2839258A priority Critical patent/CA2839258A1/fr
Publication of WO2012174524A2 publication Critical patent/WO2012174524A2/fr
Publication of WO2012174524A3 publication Critical patent/WO2012174524A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5018—Thread allocation

Definitions

  • the present invention relates to systems and methods for providing telematics services to vehicles. More particularly, the present invention pertains to telematics systems and methods utilizing a flexible, modular, and scalable cloud-based telematics platform operable to deliver data intensive telematics services to various customers with a high level of service customization, but without having to develop complete custom solutions.
  • Telematics includes the integration of wireless communications, vehicle monitoring systems, and location devices. Such technologies in automotive communications combine wireless voice and data capability for management of information and safety applications.
  • Telematics technology is in a period of transition.
  • the traditional perspective of telematics as a way to track vehicles as assets has given way to a comprehensive view of telematics as a core function that supports safety, security, and entertainment in the vehicle.
  • telematics is becoming the key mechanism by which drivers extract additional value from their investment in their cars. Manufacturers can exploit this mechanism and thereby improve the customer's perceived value of the product, and engender loyalty in an increasingly fickle customer base.
  • a telematics system includes a cloud-based telematics platform capable of supporting new OEMs with a high level of service customization, but without the historical overhead of developing a completely custom solution.
  • the flexibility of the telematics system is derived from the basic principle of keeping internal data and processing separate from the external OEM- specific data and processing. Additional benefits are obtained through a modular and scalable approach to implementing the telematics system. The underlying flexibility of the system also allows major, external components to be changed out with minimal impact to the system. The telematics system can be deployed in an environment where a fully custom solution would be cost-prohibitive.
  • Customization is achieved through a combination of configuration options, tunable service routing rules, and customer preferences.
  • the telematics system can be accessed through a number of delivery channels including operator, interactive voice response (IVR), and web interfaces.
  • IVR interactive voice response
  • a cloud-based telematics system provides telematics services to connected vehicles through open web services that allow the integration of various subsystems with existing and new end points within the telematics supply chain.
  • the subsystems of the telematics system include a telematics services subsystem, a gateway services subsystem, an interactive voice response (IVR) subsystem, a consumer web interface, a call center interface, a call center user interface, a telephony interface, a data services subsystem, and a content services subsystem. These subsystems communicate with each other through standardized, internal interfaces. Translator and adapter plug-ins are used to convert data into a structure that is compatible with the method in which it will be extracted or accessed, thereby providing an interface through which various applications can connect and allowing integration of new sources of data in a short amount of time.
  • IVR interactive voice response
  • a method for providing abstraction in a telematics system includes providing a telematics system with components.
  • the components include a translator that converts messages received from a vehicle into a canonical form and an adapter that converts data received from an external source into a canonical equivalent.
  • the translator interprets the received messages and routes the received messages to a correct component of the telematics system.
  • the adapter is operable to allow a content services subsystem to deliver the received data.
  • determining an origin of the messages or the data is unnecessary in order for at least one of the translator and the adapter to use the messages or the data.
  • the received data comprises at least one of points of interest, contacts, vehicle data, and other data stored outside of the telematics system.
  • the components of the telematics system are modular and discrete.
  • code for the components of the telematics system is free of original equipment manufacturer (OEM) specific details.
  • the components are discrete and additional instances of at least one of the discrete components are added to increase capacity.
  • the telematics system is implemented as a stand-alone system.
  • the telematics system is implemented as an integrated platform operable to service many customers.
  • the telematics system uses code frameworks to standardize a behavior of common parts of the telematics system.
  • the code frameworks are operable to send and receive the data.
  • the code frameworks are operable to audit operations.
  • the code frameworks are operable to read and write configuration data.
  • the code frameworks are operable to handle error conditions. In accordance with still a further mode of the invention, the code frameworks are operable to route service requests.
  • the telematics system is provided with a set of routing rules that are consulted for each instance of a service request.
  • a telematics system comprises components including a translator operable to convert messages received from a vehicle into a canonical form, to interpret the received messages, and to route the received messages to a correct one of the components and an adapter operable to convert data received from an external source into a canonical equivalent and to permit delivery the received data by a content services subsystem.
  • the telematics system is modular and the components are discrete components.
  • the components are implemented as a stand-alone telematics system.
  • the components are
  • FIG. 1 illustrates the cost-benefit tradeoff between highly-customized and highly- standardized approaches
  • FIG. 2 is a block diagram of a PaaS-based telematics system in accordance with an exemplary embodiment
  • FIG. 3 is a diagrammatic illustration of an exemplary content services subsystem of the telematics system of FIG. 2;
  • FIG. 4 is a pictorial representation of how frameworks relate to the functional components within the telematics system of FIG. 2;
  • FIG. 5 is a block diagram of an architecture of a telematics system in accordance with an exemplary embodiment
  • FIG. 6 is a block diagram depicting a telematics system interface in accordance with an exemplary embodiment
  • FIG. 7 is a table of exemplary telematics services deliverable by a telematics system in accordance with an exemplary embodiment
  • FIG. 8 is a block diagram depicting a data sync process for exposing and exchanging data with third parties in accordance with an exemplary embodiment
  • FIGS. 9 and 10 are tables of exemplary events for which the data sync process of FIG. 8 can be used.
  • Relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.
  • the terms "comprises,” “comprising,” or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.
  • An element proceeded by "comprises ... a" does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.
  • the term “about” or “approximately” applies to all numeric values, whether or not explicitly indicated. These terms generally refer to a range of numbers that one of skill in the art would consider equivalent to the recited values (i.e., having the same function or result). In many instances these terms may include numbers that are rounded to the nearest significant figure.
  • program is defined as a sequence of instructions designed for execution on a computer system.
  • a "program,” “software,” “computer program,” or “software application” may include a subroutine, a function, a procedure, an object method, an object implementation, an executable application, an applet, a servlet, a source code, an object code, a shared library/dynamic load library and/or other sequence of instructions designed for execution on a computer system.
  • the telematics system 210 provides data intensive telematics services to connected vehicles through a telematics platform of interfaces that simplify the creation of connected vehicle solutions for automotive OEMs, their partners, and any other potential third party customer.
  • the exemplary telematics system 210 includes a number of components or subsystems: a telematics services subsystem 212; a gateway services subsystem 214; an interactive voice response (IVR) subsystem 216; a consumer web interface 218; a call center interface 220 and call center user interface 222; a telephony interface 224; a data services subsystem 226; and a content services subsystem 228.
  • IVR interactive voice response
  • the telematics system 210 provides an end-to-end telematics solution through open web services that allow integration of the subsystems 212, 214, 216, 218, 220, 222, 224, 226, 228 with existing and new end-points within the telematics supply chain.
  • External integration points within the overall system 210 are designated by the dashed lines in each of the subsystems 212, 216, 218, 220, 224, 226, 228, which communicate with each other through standardized, internal interfaces with strictly defined data and invocation sequences. These interfaces are referred to as the "canonical" telematics system interfaces. These interfaces are consistent, regardless of the specific OEM that has been implemented.
  • the telematics system 210 is operable to integrate with any telematics device and mobile network operator (as illustrated at blocks 240, 242, 244, 246, 248, 250), which are highly variable and subject to change with each OEM or customer deployment.
  • the telematics system 210 (through its platform of subsystems 212, 214, 216, 218, 220, 222, 224, 226, 228) provides over-the-air vehicle integration, PBX and telephony integration, content aggregation and integration, customer relationship management (CRM) and back office integration, IVR integration, call center integration, web portal integration, and smartphone integration.
  • the telematics services subsystem (TSS) 212 is the core telematics engine that acts on the telematics requests, manages service entitlement and device authentication, accesses data and routes to the appropriate individual and internal service components.
  • the TSS 212 provides open interfaces to a number of service categories, e.g., safety and security, remote services, driver interactive vehicle applications (DIVA) services, diagnostics, navigation and infotainment.
  • service categories e.g., safety and security, remote services, driver interactive vehicle applications (DIVA) services, diagnostics, navigation and infotainment.
  • DIVA driver interactive vehicle applications
  • the gateway services subsystem (GSS) 214 is responsible for network communication; telematics control unit (TCU) communication, protocol processing, encryption and transaction routing.
  • the GSS 214 connects to any type of wireless or wired network and is built such that network transports and protocols are added as plug-ins to support future transports as well as telematics protocols.
  • the GSS 214 based on business rules associated with transport, protocol and device type, routes both data and voice to the TSS 212.
  • the GSS 214 also provides an open web services interface that translates protocol into an application level interface and vice versa.
  • the GSS 214 routing rules, that control where a call type lands, are configured in a database and can be modified at anytime. Web interfaces update the routing rules.
  • the telematics system 210 provides over the air vehicle integration through a platform interface that simplifies integration with any telematics device through the management of all low- level processing while providing a high-level interface that allows developers to build simple protocol translator plug-ins 230 for various telematics devices, as will be described in further detail below.
  • the interface supports the following: device gateway for over the air communication of device protocol, call routing based on configurable parameters and a set of business rules, voice routing, wireless network management, and traffic monitoring.
  • the telephony interface subsystem 224 has a built-in telephony engine that supports all major commercial computer telephony integration (CTI) systems. Additional plug-ins can be developed for additional PBX/CTI support.
  • CTI computer telephony integration
  • the data services subsystem 226 includes a data services engine that supports an open web services interface. This allows any third party developer to integrate their CRM solution into the connected vehicle platform.
  • the connected vehicle platform does not depend on the availability of the CRM system for customer or vehicle data as the system automatically keeps a copy of the primary customer and vehicle data in its own database.
  • the content services subsystem (CSS) 228 is a global platform designed to integrate various disparate sources of data and make them available to call centers and end users in vehicles or using mobile devices. Multiple inputs to the CSS 228 system, both stored locally and accessed through the internet, are used to provide maximum flexibility and richness of content. Data that is stored locally is taken from the original native format and converted into a structure that is compatible with the method in which it will be extracted and/or accessed. For example, the structures of POI, Traffic information, and other data sources are preserved and stored into a relational database where the content gateway then accesses the data and leverages the querying ability of the database. Data that is available from online sources can also be accessed through the same content gateway, thereby providing one interface through which the applications connect and allowing integration of new sources of data in a short amount of time.
  • the IVR subsystem or platform 216 provides an extensive voice and data interface that supports speech recognition technologies.
  • the IVR subsystem 216 exposes all connected vehicle functions and services to the integrator and allows custom prompt to be built for specific brand and service types.
  • IVR allows subscribers to interact with the IVR subsystem 216 on a self-service basis using the telephone as the communications channel.
  • the IVR application performs the same functions as a human operator in a more cost effective and scalable way.
  • the telematics system 210 treats both operators and IVR as delivery channels for the service. This model can be extended to include self-service applications accessed through the web services, provided by the consumer web interface 218, which allow the building of customer web portals or mobile applications that take advantage of self-service functions.
  • the call center interface 220 provides a comprehensive call center integration interface that allows a third party call center to integrate the platform of the telematics system 210 into the applications and tools used by the call center.
  • the interfaces supplied provide access to telephony data, vehicle data, and customer data.
  • the platform leverages the existing routing rules used by the third party call centers to route both voice and data to an available agent.
  • a call center agent is able to receive a call (both voice and data). Further, the agent is able to pull customer and vehicle data from the connected CRM system as well as the available content sources. Finally, the agent is able invoke commands to send data to the vehicle.
  • the customer web interface (CWI) 218 of the telematics system platform allows third party developers to create web and Smartphone apps that access or control the vehicle.
  • the CWI 218 supports authentication and authorization, which utilize enrollment information to allow access to the system functions and the vehicles services.
  • the CWI 218 supports several categories of services and functionality including POI, geo-fence, DIVA, and remote access.
  • the telematics system 210 does not need to know anything about how the service is being delivered, which makes it much easier to connect the telematics system 210 to new delivery channels like SMS-text and e-mail.
  • data coming into the telematics system 210 from the outside is separated from how it is used, data from the telematics system 210 can also be exposed to an end user in a number of different ways.
  • Traditional telematics applications are operator-assisted. That is, a vehicle driver interacts with an operator at a call center and the operator interacts with the telematics system 210 through a call center application running on their computer and supported by the call center interface 220 and call center user interface 222
  • POI Point Of Interest
  • traffic data For example.
  • POI Point Of Interest
  • Each of these sources may format their data in a different way even though POIs are fundamentally the same. If the system were developed in a way that required each subsystem to know the details of every possible POI format, the code would quickly become cumbersome and difficult to maintain over time. To avoid such a situation, the telematics system 210 uses a technique called abstraction to separate the data from the details of where the data came from. Specifically, the telematics system 210 converts any data coming into the system from "outside" into a standardized or “canonical” form.
  • All parts of the telematics system 210 understand this form, and are able to operate on the data regardless of where the data came from. This does not change the form of the data from the provider; it just has to pass through a piece of code that does nothing but convert data between the provider's format and the telematics system canonical format. This also means that if an OEM wants POIs from BingTM Maps rather than NavteqTM, for example, the only part of the telematics system 210 that has to be changed is the specialized piece of code, called an "adapter.”
  • the telematics system 210 is able to integrate any telematics device through the use of translators 230 that plug into the gateway services subsystem or platform 214.
  • Translators 230 are specific to the protocol used to communicate with the TCU of a vehicle and they are responsible for converting messages from the vehicle into their canonical form so that the request can be interpreted and routed to the correct component for processing.
  • the telematics system 210 uses adapters 232 to convert external data formats into their canonical equivalent.
  • adapters 232 plug into the content services subsystem or platform 228 to convert any source or type of content into its canonical form, which allows the CSS 228 to deliver the assorted content to telematics customers.
  • the telematics system 210 may include any number of adapters 232 plugged into any of the other subsystems 212, 214, 216, 218, 220, 222, 224, 226 for data conversion.
  • the common code of the telematics system 210 is protected from the system interfaces by using small pieces of code, i.e., the translators 230 or adapters 232. This ensures that the subsystems 212, 214, 216, 218, 220, 222, 224, 226, 228 do not need to know where the data came from in order to be able to use the data.
  • abstraction i.e., separating how the data is acquired from how it is to be used, is a key principle in the exemplary telematics system 210.
  • the representation of data in canonical form also applies to the messages that are exchanged by the components of the telematics system 210 itself. Every part of the system 210 uses only the common form for all data. Crash data, remote service data, and diagnostic data always look the same inside of the telematics system 210, no matter what OEM or TCU model is being serviced. Knowledge of OEM-specific protocols, message formats and procedures is isolated to the periphery of the telematics system 210, allowing the system's core to remain unchanged.
  • FIG. 3 is a diagrammatic illustration of a content services subsystem 228 in accordance with an exemplary embodiment.
  • the CSS 228 provides a platform capable of real-time content integration from a variety of content sources, e.g., social networks, map servers, and various internet applications.
  • Architecture 228 may be implemented in, for example, telematics system 210.
  • Content platform 302 has a report application programming interface (API) module 326, a profile management module 328, a report import module 316, and a plurality of real-time interfaces 304, 308, 312, 318.
  • Content platform 302 receives report queries from report engine 324 at report API 326.
  • Content platform 302 connects to social media server 306, maps server 310, and personal POI server 314, via real-time interfaces 304, 308, and 312, respectively.
  • API application programming interface
  • Remote import module 316 provides remote content 320 via real-time interface 318.
  • Remote content may include, but is not limited to traffic, weather, POI, News, yellow pages, songs, tagging, and/or RR.
  • the remote content may be from a public source, an OEM source, or provided by subscription.
  • Profile management module 328 is associated with profile database 334. In conjunction with database 322 and profile database 334, profile management module 328 can provide personalized POI and personalized traffic information. In addition, profile management module 328 can provide address, weather, and FCD information. Profile management module 328 provides content, information, reports, etc. via content delivery system 330 in response to requests initiated via a menu 332. Example categories that may be included in the menu 332 in order to initiate content delivery are web applications self portals, email, IVR/Voice, Mobile Applictions, Call center agent assist, and vehicle. Content may be delivered, for example, to telematics system 210.
  • translators 230 and adapters 232 transform or convert the incoming data into its canonical equivalents so that the core of the CSS 228 remains unchanged
  • Exemplary systems and processes for content delivery are described in co-pending U.S. Provisional Application Serial No. 61/497,768, filed concurrently on June 16, 2011, the contents of which has been incorporated.
  • a key feature of the telematics system 210 is the ability to minimize and isolate OEM- specific behavior. Keeping OEM details out of the core of the system 210 is, unfortunately, not entirely realistic. Beyond the mechanics of communicating with the vehicle and any potential sources of needed data, every service has specific logic associated with it. These are commonly referred to as "business rules" in the world of n-tier transaction processing. These business rules are a major component of the telematics system's core functionality. If all other OEM-specific code is at the periphery of the system 210, a question arises as to how the "minimize and isolate" philosophy is implemented at the core. The answer lies in inheritance.
  • Inheritance is a programming construct that allows common functionality to be grouped together in what is called a "parent" or “base” class. If a programmer needs code that is very similar to the base, they can modify how that base works by deriving a new class from the parent. By making use of the parent's functionality, the developer does not need to write that code again. They need to focus solely on the ways in which the derived code differs from the parent. This kind of coding is at the core of implementing services to multiple OEMs from the same code base.
  • a "geo-fence” service which generates an alert to a subscriber informing them they are outside a virtual perimeter around a specific location.
  • OEM "A” wants the geo-fence to be defined by a geographic point combined with a radius, forming a circle around the point but OEM "B” prefers that the geo-fence is defined by four geographic points, forming a quadrilateral that serves as a perimeter. It is not very efficient to write code that assumes that the perimeter is a circle and then copy that code, substituting a quadrilateral for the circle.
  • the telematics system 210 instead defines a geo-fence as the behavior required when an arbitrary perimeter is breached. This serves as the base for all geo-fence implementations.
  • the platform of the telematics system 210 allows the implementation of a new OEM to be focused in specific areas, thus reducing the scope of effort required to bring an OEM to production.
  • the functional areas that are typically affected by OEM-specific development and the types of changes required in each are detailed below.
  • the telematics system 210 in accordance with exemplary embodiments treats communications with the vehicle separately from the implementation of the telematics services. This allows the communications components to change without necessarily affecting the behavior of the service.
  • the network connection acts a pipe through which the telematics data flows. These pipes are provided by the wireless network and terminate inside the network provider's network.
  • the transport wrapper helps to regulate the amount of data that arrives at any one time.
  • the OEM generally chooses between short messages (SMS for GSM and CDMA carriers) or packet data (GPRS for GSM carriers, or lxRTT for CDMA carriers). Short messages are generally chosen for services that require little data, while packet data is generally chosen for services that produce large amounts of data.
  • the protocol establishes the rules that the telematics system 210 and the vehicle follow when communicating with each other.
  • While these components are generally very closely related, they are distinct elements within the telematics system 210. This means that there is less effort necessary to change transport wrappers, for example, and that the code that implements that wrapper can be re-used even when the network and protocol are different.
  • the telematics system 210 is implemented in a way that the "base" implementation of RDU assumes that the unlock delay is zero, thus implementing the delay for a specific OEM becomes an exercise in configuring the delay correctly.
  • the telematics system 210 is configured under the premise that all data of a specific type should look the same, regardless of the source. This means that POIs, contacts, vehicle data and other data that is stored outside of the telematics system 210 should be made to look uniform before the telematics system 210 is able to process it. By making this a valid assumption for all components within the telematics system 210, knowledge of the data has been disconnected from the business logic. This does not remove the need to be able to connect to external sources of data; it just isolates it into a specific part of the code.
  • the code i.e., content or data adapters 232, know the specifics of how POIs (for example) are stored and retrieved. Once adapters 232 have been developed for a common source, e.g., BingTM maps, they can be re-used for any OEM.
  • the telematics platform of the inventive telematics system 210 accelerates the implementation of OEM programs and improves the overall reliability of the system 210 through code re-use, isolation of OEM-specific code, the use of modern object-oriented coding techniques, and modular architecture.
  • the telematics system 210 is modular, in that each functional part of the system 210 must be in order to fit tightly with the rest of the system 210. By breaking functionality out into discrete components, it is possible to replace individual elements as needed. This may be due to specific OEM requirements or due to improvements in the implementation of a specific function.
  • a key element of modularity in the telematics system 210 is that details which are OEM-specific are not propagated into core code. This helps to keep most code re-usable by multiple OEMs and allows leveraging of that code repeatedly once it has been written.
  • the telematics system 210 needs to be able to serve both large and small OEM programs, it is important that the functional components of the system do not make assumptions about the physical deployment of the system 210. Adhering to this rule ensures maximum flexibility in deploying the system 210. Design of the telematics system 210 is performed to make possible running of the entire system 210 on a single server, although to do so would be impractical for an actual OEM. The specific benefit of this is that, as subscriber and call volumes increase, additional instances of the system components can be added to increase capacity. Adding a component this way is independent of the number and location of the other components that make up the system 210.
  • the telematics system 210 has the unusual ability to be deployed either as a stand-alone system or as an integrated platform operable to service many customers.
  • a single telematics system is capable of executing services for customers of different OEMs at the same time, even if those services behave differently.
  • the challenge in achieving this capability is not necessarily in having the system to perform multiple functions at the same time. The challenge is doing that while minimizing the duplicate functionality within the system.
  • the telematics system 210 manages multiple implementations of services efficiently and reduces the effort and time-to-market involved with launching subsequent OEM programs.
  • the telematics system 210 makes extensive use of code frameworks to standardize the behavior of common parts of the system 210. Moving data, for example, is something that every part of the system 210 has to do in a consistent, predictable way. If each component of the system 210 implemented this fundamental task differently, it is unlikely that the system 210 would be reliable or consistent.
  • Frameworks make up the "bones" of the system 210 like the framing of a house. Examples of where the telematics system 210 uses frameworks are: sending and receiving data; auditing operations; reading and writing configuration data; handling error conditions; and service request routing.
  • FIG. 4 shows a pictorial representation e.g., a diagram 400, of how frameworks relate to the functional components within the telematics system 210.
  • Diagram 400 includes a service framework 410, a computer-telephony integration (CTI) unit 404, and endpoint rules 420.
  • Diagram 400 also includes an interface 402 to telematics system 210.
  • Service framework 410 includes message processor and service engine 412, monitoring unit 414, logging unit 416, and exception handling unit 418.
  • the service framework 410 is responsible for loading the correct message processor and service engine code, depending on what kind of service request is received.
  • An advantage of the framework 410 is that, even in circumstances where the service engine 412 must be replaced for a specific OEM, the coding effort is limited to the engine itself, and none of the surrounding code is affected.
  • the telematics platform 210 provides a set of routing rules that are consulted for each service request.
  • the routing rules allow each OEM to decide how calls are handled based on OEM, service requested, country of residence, language, and other factors. Making this capability a basic function of the telematics system 210 means that OEMs are not forced into a particular service model. An OEM may also decide to segment their services in order to better support their brand strategy.
  • the telematics system 210 allows customers to establish preferences for certain types of data that they can receive. This allows them to override some of the OEM defaults with data using the customer' s personal account. News, weather, and traffic feeds are prime candidates, but any Web-accessible information source could be a data source.
  • the layered architecture of the telematics system comprises four major modules: data transport 510, message handlers 512, translators 514, and web services 516.
  • Data transport module 510 can support SMS transport protocol for communication via a client.
  • Data transport module 510 can also support SMS and TCP transport protocols for communication via a server.
  • Abstract Syntax Notation One (ASN1) encoding may be used in conjunction with the supported communication protocols.
  • Web service 516 may include device web services and telematics system client webs services.
  • Other modules may include configuration utilities module 518, routing manager module 520, session manager module 522, and common utilities module 524.
  • FIG. 5 depicts an exemplary interface between the telematics system 210 and CTI/PBX systems, in which web services are exposed as end-points.
  • the server side application is agnostic to vendor changes and provides easy scalability to new locations.
  • the flexibility in deploying the telematics system 210 also pays dividends when considering new markets. Because of the clear distinction between external and internal data, the telematics system 210 can be deployed in a third-party environment with a nominal amount of incremental effort.
  • a large OEM which already receives telematics services from the telematics system 210 in North America, wants to receive the same services in a foreign country, which imposes significant tariffs on the importation of data processing equipment and requires foreign businesses to partner with a local company instead of opening a local subsidiary.
  • the owner or operator of the telematics system 210 would have to provide servers for the core telematics system 210, desktops for the call center, localization of all user interfaces, a database server and DBMS software, content licenses for locally sourced data, etc.
  • the telematics system 210 is configured so that the platform can be deployed as a mass-market system 210. That is, the platform can be licensed as a software-only component to a foreign entity that would be responsible for all other aspects of the business. This is possible due to the separation of the telematics function of the telematics system 210 from the external supporting components.
  • the local partner would need to provide: all hardware for the runtime, call center, communications and telephony; a computer telephony integration solution with workforce automation capabilities, or software PBX; a call center user interface developed to work with the application programming interface (API); an industry-standard relational database management system (RDBMS) with SQL support; and APIs for all content providers.
  • the owner of the telematics platform 210 would provide: the telematics platform software with OEM specific functionality; software adapters for communications, computer-telephony integration (CTI), RDBMS, and content.
  • FIG. 6 is a block diagram 600 depicting a telematics system interface in accordance with an exemplary embodiment.
  • Diagram 600 illustrates an example implementation of a gateway services (GS) subsystem 602, e.g., GS 214, interfacing with a telephony server 616 using a common CTI library function 606.
  • GS 602 sends a request to initiate a telephony webservice using GS-Telephony webservice 604.
  • GS-Telephony web service 604 forwards the request to service engine 608 of a common CTI library 606.
  • Service engine 610 forwards the request to a telephony client 610.
  • a telephony server request 612 is communicated to a telephony server 616 using an API 614.
  • An event listener 618 polls messages from the telephony server 616 for events related to the request.
  • Event handler 620 sends solicited events to the telephony client 610, which, in turn, forwards the solicited events to the GS-Telephony web service 604 via the service engine 608.
  • An event handler 620 forwards unsolicited events to a Gateway Voice Call webservice 622.
  • the telematics system 210 of the present invention can be used for implementing any of the exemplary services listed in FIG. 7, in addition to any other services disclosed in U.S. Provisional Applications Serial Nos. 61/497,699, 61/497,705, 61/497,715, 61/497,768, and 61/497,849 (all of which have been incorporated by reference herein).
  • Example 7 are: ACN, automatic alarm notification, automated Diagnostic Trouble Codes (DTC) notification, curfew alert, daily route guide with traffic, eco coach, enhanced roadside, friend finder, gas price location, geo- fence, Information call (I-Call), Interactive Voice Recognition (IVR) owner's manual maintenance alert notification, operator assisted owner's manual, operator navigation, panic notification, POI download by IVR, POI download by operator, POI download from Web, provisioning, Q-feedback, recall campaign advisor, remote door control (unlock/lock), remote horn and lights, remote start climate control, restaurant ratings, SOS, Stolen Vehicle Recovery (SVR), scheduled vehicle diagnostics, song tagging/purchasing, speed alert, sports/stock/news, turn-by-turn, traffic flow accident control, vehicle immobilization/slowdown, voice text messaging, weather forecast alert, and Web diagnostics (real-time).
  • the example services may be provided in accordance with primary and secondary communication protocols.
  • Example primary communication protocols include SMS, TCP/IP, and SMS-ST.
  • FIG. 8 illustrates an exemplary process through which CRM or subscription data (e.g., subscription information for a primary subscriber, additional subscribers, or product bundles) is exposed to third parties, e.g., an OEM.
  • CRM or subscription data e.g., subscription information for a primary subscriber, additional subscribers, or product bundles
  • third parties e.g., an OEM.
  • information such as account information and all contacts, products, and start and end dates, is synced with the OEM web service.
  • the customer enrolls in a new service (block 810), either through the telematics services provider's web enrollment, through a dealer's web portal, or a customer web portal.
  • the customer enrolls through the dealer's web portal, i.e., the sales person at the dealership enters the customer's subscription data at the dealer's web portal. Customer preferences can be set at this stage.
  • the data is sent to the web server of the telematics service provider (arrow 812) and through the handler interface (arrow 814) to the CRM (arrow 816), which has all of the profile data of the customer or primary subscriber.
  • the CRM then generates and sends an XML message (arrow 818) to a data reader/writer, e.g., MQSERIES®, which sends the data to a data sync database 824 through the data sync listener (arrows 820 and 822).
  • a data reader/writer e.g., MQSERIES®
  • the JAVA® processor and web service client delivers the data from the data sync database 824 to the OEM server (arrows 826, 828, 830).
  • the telematics service provider receives an acknowledgement, e.g., a customer ID, that the data sync for the "enrollment” event was successful (indicated by the "response object" arrows 832 and 834 and the arrow 836 back to the handler interface).
  • the customer ID can then be used for subsequent data sync transactions on an account.
  • FIGS. 9 and 10 Examples of events in which the data sync process can be used to synchronize additional subscription information are shown in FIGS. 9 and 10.
  • an enrollment event has an event label of "Enrollment" and information that is sent can include account information, all contacts, all products, and start and end dates.
  • a waiver event has an event label of "Declined" and information that is sent can include account information and all contacts.
  • a product addition event has an event label of "ProductUpdate” and the information that is sent includes account identification, e.g. vehicle identification number (VIN) and customer identifier, product that was added, and start and end dates. Any product that gets added falls under this category including goodwill.
  • account identification e.g. vehicle identification number (VIN) and customer identifier
  • product that was added e.g., a product that was added
  • start and end dates e.g. vehicle identification number (VIN) and customer identifier
  • Any product that gets added falls under this category including goodwill.
  • a product cancellation event is processed the same as a downgrade event and has an event label of "ProductCancel".
  • Information that is sent for a product cancellation event can include account identification (VIN and customer ID), the product that was canceled, and start and end dates. Any product that is canceled before completion of the product's term falls under this category, including goodwill.
  • An account cancellation event has an event label of "Cancellation". In this event, all of the products on the account are canceled. Information that is sent can include account information, products that were canceled, and start and end dates.
  • a renewal event has an event label of "ProductRenewal". This event happens only for those products that are set up for automatic renewal. A customer requesting to add a product is not considered an auto renewal event. Information that is sent can include account identification (VIN and customer ID), the product that was renewed, and start and end dates.
  • An expiration of product event has an event label of "ProductExpiration”. Even when a product is set up for auto renewal, when the term for an existing product ends, the existing product is considered to be expired because the automatically renewed product has a new product code. Information that is sent can include account identification (VIN and customer ID), the product that expired, and start and end dates.
  • An expiration of a product event has an event label of "Expiration".
  • Information that is sent can include account information, the products that expired, and start and end dates.
  • a contact add or update event e.g., profile update
  • a profile update is any additions or updates made to the contacts. All of the contact information for all contacts is sent even if only one of the fields gets updated for a contact.
  • FIG. 11 illustrates a method 1100 for providing abstraction in a telematics system, according to one exemplary embodiment.
  • a translator that converts messages received from a vehicle into a canonical form is provided at step 1105.
  • the translator interprets the received messages and routes the received messages to a correct component of the telematics system at step 1115.
  • An adapter that converts data received from an external source into a canonical equivalent is provided at step 1120.
  • the adapter allows a content services subsystem to deliver the received data at step 1125.
  • determining an origin of the messages or data is unnecessary in order to use the messages or data.
  • the common code of the telematics system 210 is protected from the system interfaces by using small pieces of code, i.e., the translators 230 or adapters 232. This ensures that the subsystems 212, 214, 216, 218, 220, 222, 224, 226, 228 do not need to know from where the data came in order to be able to use the data. Accordingly, abstraction, i.e., separating how the data is acquired from how it is to be used, is a key principle in the exemplary telematics system 210.
  • messages exchanged by components of the telematics system are represented in canonical form.
  • the representation of data in canonical form also applies to the messages that are exchanged by the components of the telematics system 210 itself. Every part of the system 210 uses only the common form for all data. Crash data, remote service data, and diagnostic data always look the same inside of the telematics system 210, no matter what OEM or TCU model is being serviced. Knowledge of OEM-specific protocols, message formats and procedures is isolated to the periphery of the telematics system 210, allowing the system's core to remain unchanged.
  • the received data comprises at least one of points of interest, contacts, vehicle data, and other data stored outside of the telematics system.
  • the telematics system 210 is configured under the premise that all data of a specific type should look the same, regardless of the source. This means that POIs, contacts, vehicle data, and other data that is stored outside of the telematics system 210 should be made to look uniform before the telematics system 210 is able to process it. By making this a valid assumption for all components within the telematics system 210, knowledge of the data has been disconnected from the business logic. This does not remove the need to be able to connect to external sources of data; it just isolates it into a specific part of the code.
  • the code i.e., content or data adapters 232, know the specifics of how POIs (for example) are stored and retrieved. Once adapters 232 have been developed for a common source, e.g., BingTM maps, they can be re-used for any OEM.
  • the telematics system is modular and comprises discrete components.
  • the telematics system 210 is modular in that each functional part of the system 210 must be in order to fit tightly with the rest of the system 210. By breaking functionality out into discrete components, it is possible to replace individual elements as needed. This may be due to specific OEM requirements or due to improvements in the implementation of a specific function.
  • a key element of modularity in the telematics system 210 is that details which are OEM-specific are not propagated into core code, i.e., free of OEM-specific details. This helps to keep most code reusable by multiple OEMs and allows leveraging of that code repeatedly once it has been written.
  • the telematics system 210 needs to be able to serve both large and small OEM programs, it is important that the functional components of the system do not make assumptions about the physical deployment of the system 210. Adhering to this rule ensures maximum flexibility in deploying the system 210.
  • the design of the telematics system 210 is such that it would be possible to run the entire system 210 on a single server, although to do so would be impractical for an actual OEM.
  • the specific benefit of this is that, as subscriber and call volumes increase, additional instances of the system components can be added to increase capacity. Adding a component this way is independent of the number and location of the other components that make up the system 210.
  • additional instances of at least one of the discrete components are added to increase capacity.
  • the design of the telematics system 210 is such that it would be possible to run the entire system 210 on a single server, although to do so would be impractical for an actual OEM.
  • the specific benefit of this is that, as subscriber and call volumes increase, additional instances of the system components can be added to increase capacity. Adding a component this way is independent of the number and location of the other components that make up the system 210.
  • the telematics system is implemented as a stand-alone system.
  • the telematics system is implemented as an integrated platform operable to service many customers.
  • the telematics system uses code frameworks to standardize a behavior of common parts of the telematics system.
  • Frameworks make up the "bones" of the system 210 like the framing of a house. Examples of where the telematics system 210 uses frameworks are: sending and receiving data; auditing operations; reading and writing configuration data; handling error conditions; and service request routing.
  • the telematics platform provides a set of routing rules that are consulted for each instance of a service request.
  • the routing rules allow each OEM to decide how calls are handled based on OEM, service requested, country of residence, language, and other factors.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention porte sur un procédé permettant de fournir une abstraction dans un système télématique qui fournit un système télématique avec des composants, les composants comprenant un élément de conversion, qui convertit des messages reçus d'un véhicule sous une forme canonique, et un adaptateur, qui convertit des données reçues d'une source externe en un équivalent canonique. L'élément de conversion interprète les messages reçus et achemine les messages reçus vers un composant correct du système télématique. L'adaptateur est utilisable pour permettre à un sous-système de services de contenu de distribuer les données reçues.
PCT/US2012/042941 2011-06-16 2012-06-18 Systèmes et procédés de fourniture de services télématiques à des véhicules WO2012174524A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA2839258A CA2839258A1 (fr) 2011-06-16 2012-06-18 Systemes et procedes de fourniture de services telematiques a des vehicules

Applications Claiming Priority (14)

Application Number Priority Date Filing Date Title
US201161497934P 2011-06-16 2011-06-16
US201161497705P 2011-06-16 2011-06-16
US201161497699P 2011-06-16 2011-06-16
US201161497849P 2011-06-16 2011-06-16
US201161497768P 2011-06-16 2011-06-16
US201161497715P 2011-06-16 2011-06-16
US61/497,768 2011-06-16
US61/497,849 2011-06-16
US61/497,699 2011-06-16
US61/497,715 2011-06-16
US61/497,705 2011-06-16
US61/497,934 2011-06-16
US13/524,588 2012-06-15
US13/524,588 US20120253551A1 (en) 2009-01-30 2012-06-15 Systems and Methods for Providing Telematic Services to Vehicles

Publications (2)

Publication Number Publication Date
WO2012174524A2 true WO2012174524A2 (fr) 2012-12-20
WO2012174524A3 WO2012174524A3 (fr) 2014-05-08

Family

ID=47357802

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/042941 WO2012174524A2 (fr) 2011-06-16 2012-06-18 Systèmes et procédés de fourniture de services télématiques à des véhicules

Country Status (2)

Country Link
CA (1) CA2839258A1 (fr)
WO (1) WO2012174524A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013205392A1 (de) * 2013-03-27 2014-10-02 Bayerische Motoren Werke Aktiengesellschaft Backend für Fahrerassistenzsysteme
DE102015204336A1 (de) 2015-03-11 2016-09-15 Volkswagen Aktiengesellschaft Verfahren und Vorrichtung zur Integration von Fahrzeug-Applikationen
CN106250511A (zh) * 2016-08-03 2016-12-21 北京泓达九通科技发展有限公司 基于车辆定位数据的旅行时间信息处理方法与系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030083079A1 (en) * 2001-10-15 2003-05-01 Clark Noel E. Method and system for communicating telematics messages
US20070011278A1 (en) * 2005-07-05 2007-01-11 Seong Taeg Nou Telematics system having function of multi-service server selection, and method for providing various content services
US20100063668A1 (en) * 2008-09-05 2010-03-11 Gm Global Technology Operations, Inc. Telematics-enabled aggregated vehicle diagnosis and prognosis

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030083079A1 (en) * 2001-10-15 2003-05-01 Clark Noel E. Method and system for communicating telematics messages
US20070011278A1 (en) * 2005-07-05 2007-01-11 Seong Taeg Nou Telematics system having function of multi-service server selection, and method for providing various content services
US20100063668A1 (en) * 2008-09-05 2010-03-11 Gm Global Technology Operations, Inc. Telematics-enabled aggregated vehicle diagnosis and prognosis

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013205392A1 (de) * 2013-03-27 2014-10-02 Bayerische Motoren Werke Aktiengesellschaft Backend für Fahrerassistenzsysteme
DE102015204336A1 (de) 2015-03-11 2016-09-15 Volkswagen Aktiengesellschaft Verfahren und Vorrichtung zur Integration von Fahrzeug-Applikationen
DE102015204336B4 (de) 2015-03-11 2019-01-31 Volkswagen Aktiengesellschaft Verfahren und Vorrichtung zur Integration von Fahrzeug-Applikationen
US11135916B2 (en) 2015-03-11 2021-10-05 Volkswagen Ag Method and apparatus for integration of vehicle applications
CN106250511A (zh) * 2016-08-03 2016-12-21 北京泓达九通科技发展有限公司 基于车辆定位数据的旅行时间信息处理方法与系统
CN106250511B (zh) * 2016-08-03 2019-08-02 北京泓达九通科技发展有限公司 基于车辆定位数据的旅行时间信息处理方法与系统

Also Published As

Publication number Publication date
WO2012174524A3 (fr) 2014-05-08
CA2839258A1 (fr) 2012-12-20

Similar Documents

Publication Publication Date Title
US20120253551A1 (en) Systems and Methods for Providing Telematic Services to Vehicles
US20230363557A1 (en) System and method for locational image processing
CN107004410B (zh) 语音和连接平台
US10111034B2 (en) System and method for sound wave triggered content
US10762143B2 (en) Extension of third party application functionality for intent determination
CN102883306B (zh) 增强的智能电话车载设施
CN104756073B (zh) 用于在汽车中提供多媒体数据的装置和方法
US20140195663A1 (en) Method and System for Providing Cloud-Based Common Distribution Applications
US20130332172A1 (en) Transmitting data from an automated assistant to an accessory
CN102694857A (zh) 用于在数据网络上赠送的方法和设备
CN101103612A (zh) 普适设备对网络服务的动态可扩展轻量级接入
US8682307B2 (en) Device-interoperability notification method and system, and method for assessing an interoperability of an electronic device with a vehicle
CN110413528B (zh) 测试环境智能配置方法及系统
US20130167119A1 (en) Apparatus and method for supporting software development for vehicle
CN106302759A (zh) 一种智能车载多媒体系统及方法
CN108289118A (zh) 一种分布式消息流的管理方法和装置
CN102932516A (zh) 在基于车辆的计算系统和远程应用之间通信的设备
CN110852711A (zh) 签约方法、装置、存储介质及电子设备
US20060173689A1 (en) Speech information service system and terminal
WO2012174524A2 (fr) Systèmes et procédés de fourniture de services télématiques à des véhicules
JP7215378B2 (ja) 車載制御装置、情報処理装置、車両用ネットワークシステム、アプリケーションプログラムの提供方法、及びプログラム
CN102118702A (zh) 汽车信息系统
CN116232910A (zh) 开放云平台及其构建方法、存储介质
US20130052988A1 (en) Separable Billing for Personal Data Services
KR20140121603A (ko) 이종망 연동 데이터 전송시스템 및 그 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12801411

Country of ref document: EP

Kind code of ref document: A2

ENP Entry into the national phase in:

Ref document number: 2839258

Country of ref document: CA

122 Ep: pct application non-entry in european phase

Ref document number: 12801411

Country of ref document: EP

Kind code of ref document: A2