Not Applicable.
The present application is related to the implementation of vehicle-specific diagnostic and system reset procedures typically carried out by vehicle-specific service devices operatively coupled to the vehicle electronic control modules during a vehicle service process, and in particular, to a method and system in which multiple vehicle-specific service devices are replaced by vehicle-specific software applications residing in, and operating from, cloud-based virtual computers, enabling a service technician to select, communicate with, and couple a vehicle to an appropriate virtual vehicle-specific service device at the time of vehicle service.
As vehicles have become increasingly computerized, many diagnostic and repair procedures require a service technician to interface with the vehicle onboard computer systems or electronic control units (ECUs) via a standardized data connection commonly referred to as an OBD-II connection. For example, proper operation of many advanced driver assistance (ADAS) components on modern vehicles, such as adaptive cruise control, lane departure warning systems, collision avoidance systems, and blind spot monitoring systems must be evaluated prior to performing mechanical adjustments on a vehicle, as well as after repair or replacement of damaged or worn vehicle components. Using a generic diagnostic device or scan tool, a technician connects to the OBD-II connection and reads out various fault codes from the onboard computer systems or ECUs during a vehicle service. In some cases, commands that conduct a calibration or other service procedure are relayed to the vehicle using the same device and connection. As vehicle complexity has increased, vehicle manufacturers have incorporated increased functionality in the onboard computer systems and ECUs, often requiring vehicle-specific or manufacturer-specific diagnostic devices or scan tools to access. (
Recent industry changes require that vehicle manufacturers make vehicle-required diagnostic and scan software applications available upon request, from an accessible software archive, enabling independent shops and do-it-yourself mechanics to service vehicles, as well as dealers seeking to service off-brand vehicles. These software applications, once downloaded via a network, are installed on a local personal computer (PC) and communicate with the electronic control modules of a vehicle undergoing service via a standardized interface. Typically, the local PC includes: (1) a monitor, or other physical means of displaying electronic graphic content; (2) one or more Human Interface Devices (HIDs), the most common of which are keyboards and mice, to provide a means to interact with the environment; (3) a network interface card (NIC) to connect to various network(s) providing data and applications; and (4) a transport bus, such as a universal serial bus (USB) to connect devices such as printers, diagnostic tools, or OBD port readers to the computing environment. Usage of the diagnostic and scan software applications, once downloaded, may be restricted to use during single vehicle service via an authentication or subscription service provided by the vehicle manufacturer. Different vehicle makes and or models require different software applications, thereby requiring a service technician to locate and install appropriate applications prior to performing a vehicle service or inspection. (
While downloadable software applications enable more complete diagnostic and service of modern vehicles by a wide range of service providers, it has been found that installation of multiple downloadable software applications for different vehicle makes and models on a single PC often produces conflicts and problems. Hence, it often becomes necessary to remove the software applications following completion of a vehicle service in order to properly install different software applications required to service subsequent vehicles. Alternatively, a service shop may maintain a separate dedicated PC for each vehicle-specific software application. Failure to do so may lead to PC system crashes, failures, or improper vehicle diagnostics. Vehicle service technicians are generally not well skilled at performing software downloads, installations, and debugging procedures prior to or following each vehicle service.
Accordingly, it would be advantageous to provide vehicle service technicians with a means by which multiple vehicle-specific diagnostic and service software applications could be accessed on-demand, without requiring vehicle-specific hardware or multiple PCs, eliminating the need for the service technician to perform any local software installation and/or removal procedures as part of a vehicle service process.
Briefly stated, the present application sets forth a vehicle service system for interaction with the on-board electronic systems of a wide range of vehicle makes and models, utilizing a cloud-based or virtualized vehicle diagnostic system configured on-demand for the particular vehicle undergoing a service procedure. The vehicle service system consists of a local PC or end-user terminal with a standardized interface or transport bus for operatively coupling to a diagnostic connection onboard a vehicle undergoing service. The standardized interface or transport bus provides a pathway for bi-directional communication between external devices and the various electronic control modules and sensors onboard the vehicle. A local processing system providing a suitable graphical user interface for a service technician is operatively coupled to the standardized interface for bi-directional communication with the vehicle. The local processing system is further connected, via a communications pathway such as a NIC and network, to a remote cloud-based vehicle diagnostic application service configured to establish a virtualization environment consisting of a virtual processing system running a vehicle-specific diagnostic software application in response to a request from the service technician input through the graphical user interface. Upon activation, the vehicle-specific diagnostic software application operating on the virtual processing system communicates with the vehicle undergoing service and the service technician through the communications pathway, local processing system graphical user interface, and bi-directional pathways of the standardized interface or transport bus. Options and diagnostic results available from the vehicle-specific diagnostic software application are presented to the service technician within the graphical user interface of the local PC or end-user terminal, enabling the service technician to conduct a vehicle-specific diagnostic, inspection, or service procedure as if the vehicle-specific diagnostic software application was present on the local PC or end-user terminal. Upon completion of the vehicle service, the remote cloud-based vehicle diagnostic application service terminates the virtual processing system and vehicle-specific diagnostic software application, freeing cloud-based resources for subsequent uses. Alternatively, the virtual processing system and vehicle-specific diagnostic software application may persist, awaiting a new connection by either the same user or a new user.
In a further embodiment, the cloud-based or virtualized vehicle diagnostic application service is configured with software instructions for user authentication, access control, subscription services, and payment processing as required for regulating access to multiple vehicle-specific diagnostic software applications. The vehicle diagnostic application service provides access to a database service storing installation packages for vehicle-specific diagnostic software applications, each of which is associated with at least one specific vehicle make or model. In response to an authenticated or approved request from a service technician, the cloud-based or virtualized vehicle diagnostic application service locates and retrieves an installation package for vehicle-specific diagnostic software application within the database which corresponds with a vehicle on which the service technician is currently performing a service or inspection procedure. The cloud-based or virtualized vehicle diagnostic application service is configured to establish a virtual processing system within the cloud environment, and to utilize the installation package to install the vehicle-specific diagnostic software application onto the non-persistent virtual processing system. With the vehicle-specific diagnostic software application installed on the virtual processing system, the service technician is provided with a graphical user interface on a local processing system or end-user terminal for communicating with the vehicle-specific diagnostic software application. Bi-directional communications between the vehicle and the vehicle-specific diagnostic software application are routed through the standardized interface or transport bus, local processing system, and intervening communications links or networks to the virtual processing system, enabling the vehicle-specific diagnostic software application to conduct appropriate vehicle service or inspection procedures.
In a further embodiment, the cloud-based vehicle diagnostic application service is configured to establish multiple independent virtual processing systems within the cloud-based or virtual processing environment, enabling multiple service technicians at various physical locations to simultaneously conduct vehicle service or inspection procedures on vehicles, each utilizing a dedicated vehicle-specific diagnostic software application residing in one of the virtual processing systems.
In a further embodiment, the database service storing installation packages for vehicle-specific diagnostic software applications is configured to receive updates, revisions, and new vehicle-specific diagnostic software applications from vehicle manufacturers, enabling service technicians utilizing the cloud-based or virtualized vehicle diagnostic application service to access current vehicle diagnostic software at all times.
The foregoing features, and advantages set forth in the present disclosure as well as presently preferred embodiments will become more apparent from the reading of the following description in connection with the accompanying drawings.
In the accompanying drawings which form part of the specification:
Corresponding reference numerals indicate corresponding parts throughout the several figures of the drawings. It is to be understood that the drawings are for illustrating the concepts set forth in the present disclosure and are not to scale.
Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings.
The following detailed description illustrates the invention by way of example and not by way of limitation. The description enables one skilled in the art to make and use the present disclosure, and describes several embodiments, adaptations, variations, alternatives, and uses of the present disclosure, including what is presently believed to be the best mode of carrying out the present disclosure.
Turning to the figures, and to
The local processing system 102 is configured with an operating system and software instructions to provide a suitable graphical user interface GUI for a service technician. The local processing system 102 is further connected, via a suitable communications pathway such as a network interface card and the internet, to a remote cloud-based or virtualized vehicle diagnostic application service 202 configured to establish a session with a temporary virtual processing system 204 running a vehicle-specific diagnostic software application or vehicle manufacturer-specific API in response to a request from the service technician T input through the graphical user interface GUI. The software instructions installed at the local processing system 102 function as a broker between the local processing system 102 and the virtualization environment containing the virtualized vehicle diagnostic application service 202 and temporary virtual processing system 204. The software agent allows the local processing system 102 to view, control, and interact with the virtualization environments 202 and virtual processing system 204. The software agent may also pass data from a bus, like USB, to the remote virtual environment; this is commonly referred to as pass-through or USB pass-through.
The virtualization infrastructure 200 containing the virtualized vehicle diagnostic application service 202 and temporary virtual processing system 204 can be simple or complex, but the basic components will consist of:
Virtualization environments operate in one of two basic types: Type I and Type II Hypervisors. A hypervisor is the low-level programming designed to run multiple operating systems on a single piece of hardware. A Type I Hypervisor, often called a bare-metal hypervisor, has no other operating system running the basic computing components. Citrix Xenserver or VMware ESXi are examples of Type I hypervisors. In one embodiment, the present application utilizes VMware ESXi (Type I Hypervisor) to run 250+ servers on a single piece of equipment. A Type II hypervisor is a hypervisor that runs on top of another operating system. An example of a Type II hypervisor would be a Macintosh® application that allows a user to run a Windows 10® OS concurrently in a separate window.
Upon activation, the vehicle-specific diagnostic software application or vehicle manufacturer-specific API operating on the virtual processing system 204 communicates with the vehicle V undergoing service, and the service technician T, through the communications pathway, the local processing system graphical user interface, and bi-directional pathways of the standardized communication interface 104. Options and diagnostic results available from the vehicle-specific diagnostic software application or vehicle manufacturer-specific API are presented to the service technician T within the graphical user interface GUI, enabling the service technician T to conduct a vehicle-specific diagnostic, inspection, or service procedure as if the vehicle-specific diagnostic software application or vehicle manufacturer-specific API was present on the local processing system 102. Upon completion of the vehicle service, the remote cloud-based vehicle diagnostic application service 202 terminates the temporary virtual processing system 204 and the resident vehicle-specific diagnostic software application or vehicle manufacturer-specific API, freeing cloud-based resources for subsequent uses.
In a further embodiment, the cloud-based vehicle diagnostic application service 202 is configured with software instructions for user authentication, access control, subscription services, and payment processing as required for regulating access to multiple vehicle-specific diagnostic software applications or vehicle manufacturer-specific APIs. Different vehicle manufacturers may limit access to their vehicle-specific diagnostic software applications using different practices. For example, some vehicle-specific diagnostic software applications may be limited to use by a service technician T in association with service or inspection of a single vehicle V. For subsequent vehicles, the service technician T is required to reinstall the software to ensure use of the most up to date version. Alternatively, some vehicle-specific diagnostic software applications are accessible to a service technician T via a time-based subscription, without restriction as to the number of vehicle services or inspections. Regardless of the specific access restrictions placed on the vehicle-specific diagnostic software applications by the vehicle manufacturer or software creator, the cloud-based vehicle diagnostic application service 202 is configured to provide the service technician T with a simplified common user authentication process across a wide variety of vehicle-specific diagnostic software applications. An initial setup procedure to provide appropriate credentials and/or payment information for subscription-based services is typically required, with the authorized user's information stored in a suitable database 210 accessible to the cloud-based vehicle diagnostic application service 202. Storing the user information enables appropriate user authentication and payment information to be recalled and utilized by the cloud-based vehicle diagnostic application service 202 as required in order to permit or maintain access to the individual vehicle-specific diagnostic software applications requested by approved users. Optionally, the cloud-based vehicle diagnostic application service 202 may be configured to automatically establish, maintain, and/or renew software subscriptions for authorized or approved users, as well as store multiple passwords, access credentials, and payment information, allowing users a single-point login for multiple individual vehicle-specific diagnostic software applications.
The vehicle diagnostic application service 202 further provides access to a database service or software archive 300 storing installation packages for vehicle-specific diagnostic software applications or vehicle manufacturer-specific APIs, each of which is associated with at least one specific vehicle make or model. These installation packages or “gold” or “master images” may be created in advance for each vehicle-specific diagnostic software application or vehicle manufacturer-specific API to be made available to end users.
In response to an authenticated or approved request from a service technician, the cloud-based vehicle diagnostic application service 202 locates and retrieves (or clones) an installation package for a vehicle-specific diagnostic software application or vehicle manufacturer-specific API within the database service or software archive 300 which corresponds with a vehicle on which the service technician is currently performing a service or inspection procedure. After establishing the temporary virtual processing system 204 within the cloud environment, the cloud-based vehicle diagnostic application service 202 is configured to utilize the installation package to install or launch the vehicle-specific diagnostic software application or manufacturer-specific API into the virtual processing system 204. With the vehicle-specific diagnostic software application installed on the virtual processing system 204, a user interface for the vehicle-specific diagnostic software application or manufacturer-specific API is presented to the service technician via the graphical user interface GUI on the local processing system 102. Bi-directional communications between the vehicle V and the vehicle-specific diagnostic software application or manufacturer-specific API are routed through the standardized communication interface 104, local processing system 102, and intervening communications links such as the internet to the virtual processing system 204, enabling the vehicle-specific diagnostic software application or manufacturer-specific API to conduct appropriate vehicle service or inspection procedures.
User sessions created in response to authenticated or approved requests from service technicians T can be persistent or non-persistent. In a persistent state, when a service technician T disconnects from a virtual application session, that session waits for the service technician T to reconnect. Session “A” will always be assigned to Technician “A”, and no other service technician T can access that session. In a non-persistent state, once a service technician T disconnects from a virtual application session, the session resets, or returns to baseline. Technician A will be given the first available session, and if they disconnect to return later, they may or may not be assigned to the same session. Persistent sessions are more expensive to maintain, as a provider will always need n Ford sessions for n Ford customers. With non-persistent sessions, the virtualization system 202 can automatically manage active virtual application sessions based on workload. If only 30 of a provider's n customers are actively using the Ford application, then only 30 virtual application sessions will be created. Storage for user session data can be maintained in one of three ways:
In a further embodiment, illustrated in
In a further embodiment, the database service or software archive 300 storing installation packages for vehicle-specific diagnostic software applications is configured to receive updates, revisions, and new vehicle-specific diagnostic software application or manufacturer-specific API from third party vendors and/or vehicle manufacturers, enabling service technicians utilizing the cloud-based vehicle diagnostic application service 200 to access to the most up-to-date vehicle diagnostic software at all times.
The present disclosure can be embodied in-part in the form of computer-implemented processes and apparatuses for practicing those processes. The present disclosure can also be embodied in-part in the form of computer program code containing instructions embodied in tangible media, or another computer readable non-transitory storage medium, wherein, when the computer program code is loaded into, and executed by, an electronic device such as a computer, micro-processor or logic circuit, the device becomes an apparatus for practicing the present disclosure.
The present disclosure can also be embodied in-part in the form of computer program code, for example, whether stored in a non-transitory storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the present disclosure. When implemented in a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
As various changes could be made in the above constructions without departing from the scope of the disclosure, it is intended that all matter contained in the above description or shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
The present application is related to, and claims priority from, co-pending U.S. Provisional Patent Application Ser. No. 62/680,806 filed on Jun. 5, 2018, which is herein incorporated by reference.
Number | Name | Date | Kind |
---|---|---|---|
8688313 | Margol et al. | Apr 2014 | B2 |
9684500 | Margol et al. | Jun 2017 | B2 |
20110106374 | Margol | May 2011 | A1 |
20140249696 | Margol et al. | Sep 2014 | A1 |
20160335816 | Thoppae | Nov 2016 | A1 |
20170083874 | Hoover | Mar 2017 | A1 |
20170277527 | Margol et al. | Sep 2017 | A1 |
20180286146 | Liu et al. | Oct 2018 | A1 |
Number | Date | Country |
---|---|---|
2012087729 | Jun 2012 | WO |
Number | Date | Country | |
---|---|---|---|
20190371091 A1 | Dec 2019 | US |
Number | Date | Country | |
---|---|---|---|
62680806 | Jun 2018 | US |