WO 00/79727
`
`PCT/CA00/00712
`
`Evenr_GpsReporr_Handler0 is the method invoked when the GpsReporr signaled by the
`
`ATP is removed by the cluster process from its queue. The inputs to this method are:
`
`(i)
`
`!D_Remore_ Vehicle - which should be the unique IP address of the
`
`vehicle;
`
`Us
`
`10
`
`(ii)
`
`GpsPosz'tz'on -— which is a latitude-longitude coordinate pair. determined by
`
`the GPS receiver ofthe remote node and contained in the payload of the UDP
`
`segment received from the remote; and
`
`(iii)
`
`GpsHeaa’ing — which is a heading determined by the GPS receiver ofthe
`
`remote node and contained in the payload of the UDP segment received from the
`TCTUOIC.
`
`Event_GpsReport_HandZer (1D_Remote_Vehz'cle, GpsPosz'tz'on, Gp5Heaa’z'ng/
`I
`I
`
`Rem0te_Vehz'cle = GetRemote( ID_Rem0Ie_ Vehicle):
`
`Proximity
`
`= CompareGps(Remote_Vehicle, GpsPosirz'on,
`
`GpsHeading/,-
`
`[f(Proxz'miry) {
`
`AtpRequest( Remote Vehicle, speed, frequency, duration, amplitude ).'
`
`AtpRequest(Remote_Velzicle,f0ot brake, 0, O, 0,);
`
`Evem_Gp5Report_Handler carries out the following functions:
`
`(i)
`
`lnvokes the pn'vate function GetRemoIe using the input
`
`1D_Remote_ Vehicle.
`
`(The term private signifies that the function is usable only
`
`-31-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001363
`
`

`
`wo 00/79727
`
`PCT/CA00/00712
`
`VII
`
`10
`
`by the cluster module and is not accessible to “extemal" software modules). This
`
`searches the cluster’s container of remote vehicles for the object matching
`
`/D_Remore_ Vehicle;
`
`(ii)
`
`Uses the private function CompareGps to determine whether this vehicle
`
`is within a specified distance threshold. This function takes as inputs:
`
`(a)
`
`pointer to the Remote Vehicle object; and
`
`(b)
`
`the new GPS position and heading.
`
`The GPS position and heading of the remote vehicle are compared to the
`
`position and heading of the “local" vehicle. The “local" position and heading are
`
`maintained in the DIB (diagnostic information base). Since the ATP is a peer—to—peer
`
`protocol. cluster intelligence request/response exchanges can be symmetrical. The DIB
`
`can therefore be used by the ATP client to obtain GPS information for comparison with
`
`reports from remote nodes, as well as by the local OBD server to respond to cluster
`
`intelligence requests from remote nodes
`
`The output of CompareGps is a boolean variable (Proximity) indicating
`
`whether ATP requestslto this remote are warranted because the vehicle is within a
`
`specified distance threshold to require preventive measures if there is a sudden change in
`
`speed. Since the implementation of cluster intelligence is not within the scope of the
`
`present invention. the internal algorithm of CompareGps is not defined here. However. it
`
`should be noted that any implementation of CompareGps must account for margins of
`
`error in the accuracy of the GPS receiver where the remote position report originates.
`
`Furthermore. it may not be possible to distinguish between several remote vehicles
`
`moving in parallel in different lanes ahead ofthe “local" vehicle so that the identity of the
`
`-32-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001364
`
`

`
`WO 00/79727
`
`PCT/CA00/00712
`
`vehicle directly in front may remain indeterminate. The cluster intelligence decision
`
`algorithm may have to assume that all of these vehicles are equally important to monitor.
`
`If Proximity is TRUE, then ATP requests can be issued to the remote
`
`node’s OBD server. the responses to which enable the cluster to provide decision support
`to other intelligent modules within the complete automotive system. A minimum set of
`
`requests could consist of speed reports. at values of frequency and duration established by
`the owner of the cluster. (ie, one of the aforementioned automotive modules), and of
`
`notifications for the application of the foot brake.
`
`10
`
`15
`
`Another embodiment of the present invention is shown in figure 7 A
`mobile automotive telemetry system is shown generally at 1 10 in Figure 1. System 410
`comprises a diagnostic means 415 for monitoring the operational functions of the vehicle
`
`in which system 410 is installed and generating operational information. The generated
`operational information may be stored in a memory 420 until required. Both diagnostic
`
`means 415 and memory 420 are in communication with a server 425 which ultimately
`controls the operation of system 410.
`
`Server 425 can communicate with a remote client 430 via a data link 435
`
`To this end. server 425 comprises a means (440) to receive a request for information from
`
`remote client 430; a means (445a, 445b) to retrieve the generated operational information
`from memory 420; and a means (450) to transmit the retrieved generated operational
`information to remote client 43 0. Server 425 is a processor which is programmed to
`
`respond to requests for information from remote clients and to respond to control
`commands.
`
`Diagnostic means 415 may be a conventional. computer—based OBD
`module which monitors various operational functions of the vehicle in which system 410
`is located. Diagnostic means 415 may, for example, monitor exhaust emissions, fuel use.
`
`-33-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001365
`
`

`
`WO 00/79727
`
`PCT/CA00/00712
`
`'11
`
`l0
`
`l5
`
`ignition timing. engine temperature. speed andlor distance travelled. Diagnostic means
`
`415 receives inputs from the various vehicle sites via a plurality of communication lines
`
`460 and. after interpreting the inputs and generating formatted operational information.
`
`passes the operational information to memory 420 via communication line 465.
`
`Diagnostic modules suitable for use in the present invention are known in the art and are
`
`referred to as Electronic Control Modules (ECM) or Electronic Control Units (ECU).
`
`The specifications for the diagnostic modules may be found in Society of Automotive
`
`Engineers. "On-Board Diagnostics for Light and Medium Duty Vehicle. Standards
`
`Manual" 1997 Edition. the contents of which are incorporated herein by reference.
`
`Memory 420 may be any conventional computer memory, the size and
`
`operation of which will be dependent on the nature of the operational features of the
`
`vehicle a user wishes to monitor. The choice of suitable memory is believed to be within
`
`the purview of a person of skill in the art.
`
`In one embodiment of the present invention.
`
`system 410 comprises a memory 420 which includes 32k of non-volatile RAM and a
`
`configurable amount of additional RAM, allocated at run-time from the host processor
`
`system. Memory 420 receives the operational infomiation, generated by diagnostic
`
`means 415. via communication line 465 and stores the operational information. Memory
`
`means 420 15 in communication with server 420 and is capable of receiving instructions
`
`from server 425 and sending information to server 425 via communication lines 470a and
`
`470b. respectively. As will be apparent to a person of skill in the art. communication
`
`lines 470a and 470b may be replaced by a single communication line if the appropriate
`
`communication protocol is used.
`
`Server 425 acts as a gateway between remote client 430 and diagnostic
`
`means 415 and eliminates the requirement that remote client 430 has knowledge of the
`
`IJ '1:
`
`specialist OBD protocols of diagnostic means 415. Server 425 in effect acts as a
`
`"universal translator". allowing a remote client to interact with any diagnostic means of
`
`any vehicle. One way of achieving this end is through the implementation of a
`
`-34-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001366
`
`

`
`wo no/79727
`
`PCT/CA00/00712
`
`request/‘response protocol which acts as a proxy for the corresponding OBD protocols.
`
`Under this type of protocol. an abstract request from the remote client which is received
`
`by the server is mapped to the corresponding request under the specialist OBD protocols
`
`and is then transmitted on the diagnostic means or memory. as appropriate. ln the other
`
`1/1
`
`direction. the responses returned by the diagnostic means or memory to the server are
`
`then mapped to an abstract response which is sent back to the client.
`
`Such request/response protocols are known in the an and include. for
`
`example. IAS protocol for infrared links and UDP/IP protocol for widearea network
`
`communications.
`
`Data link 435 may be any conventional communication link, including, for
`
`example. telephony (wired and mobile wireless). specialized mobile radio (SMR),
`
`infrared and satellite (both low earth orbit (LEO) and geosynchronous). Server 425 may
`
`be provided with the hardware and operational protocols necessary for communicating
`
`with remote client 430 by a variety of means. thereby not restricting communication to a
`
`remote client having one particular type of data link. Providing server 425 with a
`
`plurality of communication protocols aids in making the system of the present invention
`
`universally acceptable.
`
`In one embodiment. server 425 is provided with infrared data link
`
`capabilities. An infrared data link between the server and the remote client provides a
`
`local wireless method of acquiring data from an OBD module. It therefore removes the
`
`need for the client's equipment to incorporate a system—cornpatible connector (ie, an
`
`OBD-connector as specified by the SAE) and to be physically joined by a cable in order
`
`to communicate with the system.
`
`I.) (/1
`
`When. for example. the client is test equipment in a garage. the use ofan
`
`infrared data link renders possible the development of service bays where information can
`
`-35-
`
`SUBSTITUTE SHEET (RULE 25)
`
`Page 001367
`
`

`
`wo 00/79727
`
`PCT/CA00/00712
`
`Ui
`
`10
`
`15
`
`be transferred almost instantaneously from the vehicle to the service technician's
`
`computer without requiring the customer to get out of the vehicle. The infrared
`
`connection may be achieved by attaching a serial infrared connector to a serial port on the
`
`server and by ensuring that there is an unobstructed path for IR transmission between the
`
`LED‘s of the infrared connector and that of the service technician's computer.
`
`As will be apparent. the reliability of an infrared data link is improved
`
`with the implementation of a robust protocol which detects transmission errors and
`
`avoids collisions by operating in a half—duplex fashion. Such protocols are known and
`
`have. for example. been implemented by computer and software manufacturers for
`
`incorporation in consumer electronic products such as micro-computers. modems and
`
`cellular phones (ie. the IrDA stack). Suitable protocols are described in Infrared Data
`
`Association. "Serial Infrared Link Access Protocol (IrLAP)". Version 1.1. June 1996 and
`
`Infrared Data Association. "Link Management Protocol". Version 1.1. January 1996, the
`
`contents of both of which are incorporated herein by reference.
`
`Through compliance with these infrared protocols, the server achieves a
`
`goal of rendering client test equipment independent of the OBD protocols. Accordingly.
`
`any micro-computing equipment which is infrared—aware, such as a desk-top, notebook or
`
`palm—top (Personal Digital Assistant or PDA) can effectively become a remote client.
`
`In an alternative embodiment. the infrared data link may be replaced or
`
`enhanced by incorporating mobile wireless data links, coupled with the UDP/LP
`
`infrastructure for peer-to-peer client/server exchanges over a wide area network. This
`
`adaptation of the system extends the range of the services offered by the server beyond its
`
`capabilities with only the infrared connector and data link. The principles described in the
`
`previous sections remain the same. with the exception that access to OBD information no
`
`longer requires that the vehicle be moved within infrared detection range (typically 2-5
`
`metres) of the test equipment. The vehicle can be in any location which is reachable on
`
`the Internet. Via a mobile data link.
`
`-36-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001368
`
`

`
`wo 00/79727
`
`PCT/CA00/00712
`
`In
`
`15
`
`The system of the present invention may further comprise a means to
`
`transmit generated operational information to a remote client. in the absence of a request
`
`from the client. when the generated operational infonnation satisfies predetermined
`
`criteria. Such transmissions of the generated operational information implies that server
`
`25 effectively becomes a client with respect to a remote site which is capable of logging
`
`the transmission. This functionality can be achieved by utilizing the peer-to-peer
`
`communication architecture described above and is useful in, for example,
`
`alarrrv emergency situations.
`
`If. for example. while monitoring the exhaust emissions of a vehicle on the
`
`road. the level of carbon monoxide in the exhaust gases exceeds a predetermined level.
`
`the diagnostic means can communicate this information directly to server l25 via
`
`communication line 175. Server 125 can then transmit an alarm report to a remote site
`
`advising of the problem. This report can be transmitted in real—time, allowing the
`
`problem to be dealt with immediately, rather than having to wait until the vehicle
`
`undergoes routine servicing and diagnosis. days or even months after the problem has
`
`first come to light.
`
`It is envisioned that the threshold values for alarms. as well as the
`
`frequency and duration of the alarm message, can be configured either directly at the
`
`server during installation or servicing, or by using remote commands from the client.
`
`The system described herein may also incorporate lntemet access
`
`technology for the drivers or passengers. The existing method of lntemet access for
`
`individual personal computers (PC) is well-known. The PC establishes a serial link with a
`
`computer which has a permanent Internet (IP) address. The latter computer. for the
`
`purposes of this description. can be called a gateway. The serial link is physically either
`
`a direct cable connection or via a telephone circuit. using modems at both ends of the
`
`link. The PC does not have a permanent IP address. It is assigned a temporary IP address
`
`-37-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001369
`
`

`
`W0 00/79727
`
`PCT/CA00/00712
`
`()1
`
`10
`
`by the gateway for the duration of the connection. Therefore. if the link is maintained via
`
`a telephone circuit, then the connection automatically terminates when the circuit is
`
`dropped and the temporarily assigned IP address ceases to be valid.
`
`One of the conventional methods of Internet access from a vehicle follows
`
`the technique described above. using an analog cellular phone and a cellular modem. By
`
`connecting the PC to the cellular modem. the driver/passenger can obtain a temporary IP
`
`address in the same fashion as with wired telephony.
`
`Another method of Internet access from a vehicle is a technology called
`
`Cellular Digital Packet Data (CDPD), which is a form of packet-switching overlaid on the
`
`existing analog cellular infrastructure in the United States. CDPD operates with a portion
`
`of the bandwidth of the analog cellular system and provides a multiple access data link
`
`technology within each cellular base station’s territory of coverage. However. contrary to
`
`the method already described, the network architecture of CDPD also allows each access
`
`device (C DPD modem) to have its own permanent IP address. Therefore. no dial—up
`
`connection is required to establish the presence of the PC on the Internet. It suffices for
`
`the PC to be connected to the CDPD modem (which is typically in the form ofa credit-
`
`card style PCMCIA card) for any Internet traffic from another location to reach the PC.
`
`IP V6 is a new version of the Internet Protocol. One of the design
`
`objectives of [P V6 is to enable portable computing devices (notebooks. palm-tops. etc.)
`
`to have permanent IP addresses which can be reached regardless of where the portable
`
`device is physically connected to the lntemet. Therefore. the device could be connected.
`
`at different times. to both an office LAN (Local Area Network) as well as a residential
`
`LAN. without requiring manual intervention by a network administrator in either LAN to
`
`ensure delivery of Internet traffic. This is achieved by ensuring that both LAN’s have at
`
`least one node (computer) which acts as a "Mobility Agent". The Mobility Agent
`
`incorporates software which implements [P V6 and related protocols. The purpose of the
`
`-33-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001370
`
`

`
`wo oo/79727
`
`PCT/CA00/00712
`
`mobility—related functions in this software is to ensure that roaming computing devices
`
`are automatically "discovered" when they establish a link to the Mobility Agent and that
`
`the rest of the Internet is informed of the new path which must be used to route traffic to
`
`the roaming device, Only those routers in the Internet which have been upgraded to
`
`Ur
`
`support [P V6 will participate in this function.
`
`A Mobility Agent can reside in a mobile environment as well as a fixed
`
`LAN. This scenario is a distinct departure from the existing models of Internet access
`
`already described. A mobile Mobility Agent. installed in a vehicle in the form of a mobile
`
`computer. can effectively "host" any IP V6-enable portable computing device. provided
`
`that it has a wireless data link to a network which is capable of routing packets on the
`
`Internet. such as CDPD. The implication is that ifa vehicle is equipped with a Mobility
`
`Agent using. for instance. CDPD. then any portable device which a driver or passenger
`
`wishes to use in the vehicle to obtain access to the Internet does not also need the CDPD
`
`modem. It only requires the IP V6 software.
`
`In order to equip any vehicle with IP V6 support. a hardware platform is
`
`required to host all of the required protocols and to provide the data links for portable
`
`devices trying to connect to the Mobility Agent.
`
`In order to support the SAE diagnostic
`
`test modes in the remote fashion described herein. the server contains all of the
`
`components which will also allow it to function as a mobile Mobility Agent.
`
`It is envisioned that the Infrared port (and I_tDA protocols). which is
`
`primarily useful for OBD diagnostic test modes while the vehicle is stationary and being
`
`examined. can ''double'' as an in-vehicle wireless point of entry to the internet for portable
`
`devices operated by the driver/passengers.
`
`Another embodiment is shown in figures 8a. 8b which provides an
`
`integrated circuit board for a vehicular computing device which supports the following:
`
`-39-
`
`SUBSTITUTE SHEET (RULE 25)
`
`Page 001371
`
`

`
`wo 00/79727
`
`PCT/CA00/00712
`
`a) Acquisition of diagnostic data via an automotive data bus interface (or directly
`
`through analog and digital inputs) and storage of the data.
`
`b) Data communications using spread spectrum radio in accordance with the IEEE
`
`802.1 l specification for wireless local area networks.
`
`c) Reception of signals from Global Positioning System satellites and
`
`determination of position. heading and speed based on these signals.
`
`C1) The IEEE 802.1 1 protocol stack is implemented in an additional task executed
`
`by the host CPU. Depending on the choice of processing resources. the GPS
`
`position determination may be carried out by an additional task executed by the
`
`lO
`
`host CPU.
`
`In both Figures 8a) and 8b), the CPU board 510 comprises the Universal
`
`OBD Server host system into which both the spread spectrum modem and GPS receiver
`
`functions are integrated in the form of chipsets.
`
`In Figure 8a). spread spectrum transceiver circuitry 512 comprises the RF
`
`processing functions required for implementation of a spread spectrum radio modem.
`
`These are embodied in a series of semiconductor devices constituting a chipset for
`
`integration of spread spectrum radio in a host CPU board. As these devices constitute
`
`externally defined components that are integrated in the present invention. only those
`
`components that interface with the host system are numbered.
`
`Host CPU 520 communicates with spread spectrum transceiver circuitry
`
`512 through two (2) serial interfaces. Serial interface 514 handles inbound data received
`
`from the sequence generator 516 while serial interface 518 handles outbound data sent to
`
`the decimator 519.
`
`-40-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001372
`
`

`
`wo oo/79727
`
`PCT/CA00/00712
`
`ll]
`
`l0
`
`The embedded software required to drive the spread spectrum transceiver
`
`IS an implementation of the IEEE 802.1 1 specification. executed by the host CPU. The
`
`functional interface between the host CPU and the spread spectrum sub-system
`
`corresponds to the interface between the two bottom layers of the IEEE 802.1 1 physical
`
`layer architecture. The lower layer is called the Physical Medium Dependent (PMD) sub-
`
`layer. which is embodied in the spread spectrum transceiver circuitry. The upper layer is
`
`called the Physical Layer Convergence Procedure (PLCP) sub-layer, which constitutes
`
`the lowest level of the protocol stack implemented in software to be executed by the host
`
`system.
`
`Similarly. in Figure 8 b), GPS reception circuitry 542 comprises the RF
`processing functions required for implementation of a GPS receiver. These are embodied
`
`in a series of semiconductor devices constituting a chipset for implementation of a GPS
`
`receiver. As these devices constitute extemally defined components that are integrated in
`
`the present invention. only those components that interface with the host system are
`
`l5
`
`numbered.
`
`Yet another embodiment is shown in figures 9 to 15. The term
`
`".4 utomotive Telemetry " refers to the conveyance of operational data from a mobile
`
`vehicle to a regulatory or maintenance authority as well as to other. neighboring mobile
`
`vehicles. The data transmitted are acquired directly from analog and digital sensors. the
`
`in—vehicle data bus, ECU and from a GPS receiver. The data are conveyed via a wireless
`
`packet—oriented data links provided by terrestrial RF packet networks. spread spectrum
`
`and satellite.
`
`An Automotive Telemetry System according to the present invention may
`
`be configured to enable interested parties (regulatory agencies. OEM's. dealers) to obtain
`
`critical automotive performance information in a wireless manner. It is believed that a
`
`system according to the present invention may also be configured to enable:
`
`-4]-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001373
`
`

`
`W0 00/79727
`
`PCT/CA00/00712
`
`[II
`
`10
`
`15
`
`— reliable. substantially error-free data communications between the on-board
`
`CPU and persistent data storage;
`
`- high—level services in the form of API‘s (Application Programmer Interfaces)
`
`for real—time alarm monitoring, trending and back-office decision—support
`
`systems. IT developers responsible for maintenance. performance monitoring and
`
`automotive engineering systems can invoke high-level services that make the
`
`C AN-bus. or any sensors and actuators. appear as though they are directly
`
`connected to the fixed—location host system.
`
`- flexible communications architecture enabling many—to—many, simultaneous.
`
`multiple virtual connections between on-board CPU’s and fixed—location host
`
`systems. This means that both the on—board CPU and the ground-based
`
`workstation can maintain client-server relationships with several peers at the sa.me
`time.
`
`on-board filtering intelligence and remote configuration capability. The on-board
`
`CPU should have the ability to restrict real—time transmission of diagnostic data
`
`according to threshold levels that can be dynamically changed from a fixed-
`
`location host. In addition. the host should also be able to remotely configure the
`
`frequency and duration of telemetry reports as well as logging to nonvolatile ram
`
`(NOVRAM);
`
`— minimal use of wireless bandwidth. There is an inherent economic cost
`
`associated with the deployment of infrastructures supporting wireless data links.
`
`regardless ofthe method used to recover this cost. Therefore both the application
`
`-42-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001374
`
`

`
`wo 00/79727
`
`PCT/CA00/00712
`
`and the communication software should. where possible. minimize the use of
`
`these links through such methods as exception-driven reporting and data
`
`compression.
`
`An exemplified system according to the present invention has three components:
`
`U:
`
`10
`
`— Universal On-Board Diagnostic (UOBD) Server (in-vehicle telemetry
`
`computer)
`
`— Communications Protocol Stack
`
`- Application Programmer interface (API)
`
`A hardware instantiation of the in-vehicle UOBD Server has been built
`
`based on an embedded 80386 CPU and a hard real-time multitasking kernel. The cuirent
`
`model incorporates the following features:
`
`- 512KB flash memory (192 KB for data logging)
`
`— 512 SRAM
`
`— 8 A/D channels for analog sensor inputs
`
`— 8 digital channels for discrete inputs (each channel configurable as an output)
`
`- CAN-interface
`
`- RS-485 serial ports for interface to J—l708 bus (heavy trucks and buses)
`
`- 2 RS-232 ports for PPP and/or IIDA (Infra.Red) connections with external
`
`computing devices.
`
`— GPS receiver with NMIEA-compliant data link to the CPU
`
`- RF packet radio network interface (Mobitex or ARDIS)
`
`-43_
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001375
`
`

`
`W() ()()/79727
`
`PCT/CA00/00712
`
`- Spread spectrum data link (2.4 GHz ISM band. frequency hopping CMSA/CA
`
`protocol)
`
`Real-Time Executive
`
`VJI
`
`10
`
`._a (ll
`
`The operating kernel adopted for the UOBD is RTEMS (Real-time
`
`executive for multi—processor systems). However. the entire body of software embedded
`
`in the UOBD (with the exception of the real-time kernel itself and bootstrapping code) is
`
`capable of running in alternative operating environments. This is achieved through the
`
`definition of an abstract operating system in terms of an object-oriented abstract base
`
`class. with specific instantiations for whatever operating environments are required.
`
`In particular. a Windows NT instantiation of the operating environment
`
`has been developed for emulation and testing of the embedded system.
`
`C ornmunications Sub-System
`
`The communications sub-system is a protocol stack which supports any
`
`combination of terrestrial R_F packet network. satcom packet networks and short—range
`
`spread spectrum data links. As shown in Figure 9, the software architecture treats each
`
`wireless data link as part of a sub-network according to the lntemet paradigm.
`
`The Intemet standards are implemented within the protocol stack so that.
`
`ifrequired. the UOBD Server can become addressable on the Internet. Internet
`
`accessibility to the UOBD Server is an option which facilitates remote diagnostics by a
`
`-44-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001376
`
`

`
`WO 00/79727
`
`PCT/CA00/0071 2
`
`IJI
`
`10
`
`15
`
`variety of authorized clients. The protocol capabilities of the device include both PPP
`
`and IrDA (InfraRed) which provide connectivity to other devices in the vehicle such as
`
`palm—tops or notebook computers.
`
`The architecture of the communications sub—system is designed to provide
`
`an infrastructure for "seamless" peer—to-peer communications between the vehicle and a
`
`fixed-location host system or another vehicle.
`
`The following sections describe the various layers of the protocol stack in
`
`more detail.
`
`Session Layer: Automotive Telemetry Protocol
`
`The Automotive Telemetry Protocol (ATP) provides a simple and effective
`
`bi-directional request—response mechanism. From the vehicle. ATP allows the diagnostic
`
`monitor embedded in the UOBD Server to report fault conditions to a host system
`
`application. In the reverse direction. diagnostic inquiries and parameter configurations can
`
`be issued from the host. The ATP message syntax is similar to that of SNTVEP and contains
`
`streamed versions of Object Identifiers (OID’s) as a means of specifying the performance or
`
`operational parameter to which the message pertains.
`
`Figure 10 illustrates this mechanism with the request initiated from a fixed
`
`location host. However, the implementation of the ATP supports both client and server
`
`functionality in either the host or the UOBD Server. As such, the UOBD Server may provide
`
`simultaneous OBD services to more than one (authorized) OBD "client".
`
`Sub—net and DataLink Layers: Hybrid RP
`
`.45.
`
`SUBSTITUTE SHEET (RULE 25)
`
`Page 001377
`
`

`
`wo 00/79727
`
`PCT/CA00/00712
`
`‘)1
`
`10
`
`15
`
`Short—range spread spectrum data links provide apowerful complement to RF
`
`packet networks for vehicle-to-vehicle telemetry and a potentially low-cost mechanism for
`
`OBD—IH compliance monitoring. The UOBD incorporates both technologies with the
`
`intelligence to switch between them on a "least~cost" basis. In order to preserve the IP
`
`addressing mechanism allowing for a unique IP address at the interface between the UOBD
`
`Se"'er's IP module and the drivers for its wireless data links,
`
`the present system has
`
`implemented the concept of
`
`— an Hybrid Network, which is an abstraction that combines multiple physical data
`
`links. This is illustrated in Figure 11.
`
`Any node on a Hybrid Network is either an in-vehicle UOBD Server or a
`
`Hybrid Network Gateway (HNG). This is a ground—based 113 gateway to the Hybrid Network
`
`and is functionally symmetrical to the UOBD Server. It has an EP module boundto a network
`
`interface for the Hybrid Network. This network interface has a unique IP address.
`
`The current HNG resides on a dedicated Windows NT workstation and
`
`effectively provides an IP-level gateway between the Hybrid Network and the rest of the
`
`Internet or corporate Intranet.
`
`The complete protocol stack for a hybrid network node is illustrated in Figure
`
`9. At the lowest level of this stack are data link drivers for RF packet networks. A
`
`combination of such data links is subsumed by a single abstract Hybrid Network interface.
`
`which is responsible for switching outbound transmissions over the least—cost data link in a
`
`manner that is transparent to the IP. The "cost" of using any given wireless data link is
`
`expressed as a measure of "impedance", which is established in terms of the monetary cost
`
`of transmission and of the availability of service.
`
`-45-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001378
`
`

`
`WO 00/79727
`
`PCT/CA00/00712
`
`Figure 12 illustrates the mechanism implemented for switching of mobile-
`
`originated frames over the 1east—cost wireless data link. Note that this describes the protocol
`
`behavior only at the data link layer of the stack. The behavior ofthe stack at other layers is
`
`described hereinbelow.
`
`{[1
`
`l0
`
`15
`
`In part (a) of Figure 12. the UOBD CPU sencb a frame over the serial link to
`
`the primary RF radio modern (spread spectrum), which in turn successfully sends it over the
`
`airlink to a base radio modem (spread spectrum access point). From there. the payload is sent
`
`to the Hybrid Network Gateway from where it can be routed over a-network backbone
`
`(possibly the Internet) to a host system.
`
`Part ( b) of Figure 12 shows the instance where a mobile-originated frame fails
`
`to traverse the airlink. In this instance. a failure notification is received. either from the radio
`
`modem. or from a timer expiry within the CPU. The failure notification is propagated back
`
`up the protocol stack to the process which was responsible for the message contained in the
`
`frame (e.g. the ATP client or server process). which can then choose to reschedule the
`
`transmission. The failure notification also causes the impedance level for the destination
`
`address to be raised to a maximum level. The retry is therefore carried out over the alternate
`
`RF data link. The impedance will be lowered whenever a notification 15 received that the
`
`mobile has returned within "RF range" of the base.
`
`Network Layer: In-Vehicle Routing and IP Header Compression
`
`The IP implementation is intended to enable the UOBD Server to act as a
`
`gateway from the wireless HybridNetwork to a subnet of computing devices used within the
`
`vehicle. The data link used for any of the devices is PPP (point-to—point protocol) over an
`
`RS-232 serial connection. This is designed to support a palm—top or notebook computer
`
`using PPP with a direct serial link to obtain a temporary U’ address.
`
`-47-
`
`SUBSTITUTE SHEET (RULE 26)
`
`Page 001379
`
`

`
`wo 00/79727
`
`PCTICAOO/00712
`
`In many cases. the Automotive Telemetry System does not encompass more
`
`than one host site (client). The mobile UOBD Servers do not therefore need to distinguish
`
`between remote addresses. Furthermore. the HybridNetwork Gateway has address tables for
`
`resolving all IP addresses to unique physical addresses, associated with each of the RF data
`
`links. for each UOBD. Therefore. mobile—temiinated datagrams do not require an explicit
`
`destination address in transmission. Similarly, mobile-originated datagiams do not require
`
`an explicit source address in transmission. In these cases. the [P headers can be compressed
`
`from 20 to 3 bytes. without loss of information. The overhead of 3 bytes is necessary to
`
`provide a sequence number for the datagram, an identifier for the transport protocol to be
`
`l0
`
`used and the in-vehicle subnet address of the destination. Regardless of the protocol. this
`
`amount