WO2003017227A2 - System tp receive data from vehicles - Google Patents

Abstract

A system for processing sensed vehicle data includes a sensor for sensing data related to at least one characteristic of a passing vehicle and a host unit that receives sensed data from the sensor. The sensor and the host unit are integrated into a single housing. The host stores data and communicates with peripheral devices and/or with a central processing facility.

Description

SOFTWARE ARCHITECTURE OF AN INTEGRATED HOST SYSTEM FOR SENSED VEHICLE DATA

PRIORITY

[0001] The present application is a continuation-in-part of pending U.S. patent application no. 09/931,774, filed August 20, 2001, entitled Host System

for Sensed Nehicle Data, the disclosure of which is incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

[0002] The present invention relates generally to systems and methods

for processing information that is detected related to vehicles. More particularly, the present invention relates to systems and methods for handling data that is

detected relative to vehicles, including, for example, sensed vehicle emission data, sensed vehicle speed data, and captured video information related to vehicles.

BACKGROUND OF THE INVENTION

[0003] It is known in the art of vehicle emissions and traffic handling

devices to have a system mounted along a vehicle path, such as a lane of a

roadway, that can detect various characteristics of passing vehicles. For example,

such a system may include a vehicle emissions sensing device that includes a

projector/receiver element that projects a light beam across the vehicle path, has

it reflected back by a mirror on the other side of the vehicle path, and receives the reflected beam and processes the reflected beam to determine information

regarding the emissions from the vehicle.

[0004] It is also known to have a vehicle speed and acceleration

detecting system on the side of the roadway. Further, it is known to have a video

camera placed on the side of the roadway capable of capturing video images of the vehicles, for example, to determine the license plate of the vehicle.

[0005] In the exemplary known arrangement described above, each of

the three systems: (1) emissions; (2) speed and acceleration; and (3) camera, have

been known to be each connected by a respective cable to various processing

units that are located in a van positioned on the side of the road near the systems. It is known for the van to have a variety of data processing and data collection

devices so that it receives data from each of the three systems and processes it in various manners. The van generally has a method for recording data while at a

data gathering site, and is then driven to a central data processing facility in order for the data to be more fully processed at the central data processing facility.

[0006] Thus, in the known exemplary system described above, the van

operator generally drives to an emissions testing site with all of the equipment

including the three detection systems loaded in the van, then unloads these

systems and must align them as necessary. The operator then remains with the

van while the systems are operating and controls the systems and monitors the data collection while in the van. At the end of a prescribed time (i.e., a sensing

session) the operator then disassembles the various sensing equipments from the

roadway, loads them into the van, and drives to the central processing facility.

[0007] The known arrangement utilizing the van as described above

has several disadvantages. One disadvantage is that the external vehicle (i.e., the van) takes up a significant amount of space on the side of the road. Additionally,

this vehicle also can interfere with the normal flow of traffic, as motorists might

slow down as they approach the van in order to see what activities are taking place on the side of the road. This has the unfortunate consequence of precluding

proper testing of vehicles as they are normally driven. Further, the systems

generally require an attendant at all times. Also, the cables used to connect the

various devices to the van create clutter, are inconvenient, and susceptible to

damage.

[0008] Moreover, the security of the systems would be desirable if made stronger. The software run in the equipment to make the equipment operate

as desired needs to follow contemporary philosophies that blend well with

software authoring tools in vogue. Additionally, the software architecture needs

to be more flexible in its maintenance as newer versions of code are produced

throughout the life cycle of the testing equipment, and be applicable to work

across an entire network of information regarding sensed vehicles. [0009] Accordingly, it is desirable to provide a system that reduces

the size and mass of apparatus required for sensing and capturing vehicle data

along the vehicle path such as a roadway. It is also desirable to have a convenient

and secure device and method for processing sensed vehicle data and transmitting it to a central processing facility.

SUMMARY OF THE INVENTION

[0010] It is therefore a feature and advantage of the present invention to provide a system that reduces the size and mass of apparatus required for

sensing and capturing vehicle data along the vehicle path such as a roadway.

[0011] It is another feature and advantage of the present invention to

provide a convenient and secure device and method for processing sensed vehicle data and transmitting it to a central processing facility.

[0012] It is another feature and advantage to have a software architecture within such a system that utilizes contemporary software programming techniques and objects, while preserving the immediacy of data

collection in the real time for vehicles that are tested in less than one second.

Such architecture has component pieces arranged in an n-tier architecture, which

facilitates reduced maintenance of the software components throughout the life cycle of the embodiment. [0013] The above and other features and advantages are achieved

through the use of a novel host system and method for sensed vehicle data as

herein disclosed. In accordance with one embodiment of the present invention, a system for processing sensed vehicle data includes a sensor for sensing data

related to at least one characteristic of a passing vehicle and a host unit that receives sensed data from the sensor. The sensor and the host unit are integrated

into a single housing. The host stores data and communicates with peripheral devices and/or with a central processing facility.

[0014] In accordance with another embodiment of the present

invention, a method is provided for processing sensed vehicle data, comprising

the steps of: sensing data related to at least one characteristic of a passing vehicle, receiving and storing the sensed data with a host unit that is integrated into a single housing together the sensor, and communicating between the host and a

peripheral device. The peripheral device comprises at least one of a laptop computer, a Personal Digital Assistant, and a desktop computer.

[0015] There has thus been outlined, rather broadly, the more

important features of the invention in order that the detailed description thereof

that follows may be better understood, and in order that the present contribution

to the art may be better appreciated. There are, of course, additional features of the invention that will be described below and which will form the subject matter

of the claims appended hereto.

[0016] In this respect, before explaining at least one embodiment of

the invention in detail, it is to be understood that the invention is not limited in

its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried

out in various ways. Also, it is to be understood that the phraseology and

terminology employed herein, as well as the abstract, are for the purpose of

description and should not be regarded as limiting.

[0017] As such, those skilled in the art will appreciate that the

conception upon which this disclosure is based may readily be utilized as a basis for the designing of other structures, methods and systems for carrying out the

several purposes of the present invention. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do

not depart from the spirit and scope of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] FIG. 1 is a schematic plan view illustrating several elements of

a preferred embodiment of the present invention. [0019] FIG. 2 is a schematic view depicting a host and various data

input and output devices, and other devices which may be utilized in preferred

embodiments of the invention.

[0020] FIG. 3 is a schematic view depicting several modes of

communication that may be utilized between a host and various other devices in

preferred embodiments of the invention.

[0021] FIG. 4 is a schematic view of n-tier architecture technique as

applied to the preferred embodiment.

[0022] FIG. 5 is a flow chart of major components of the system

software architecture.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

[0023] The preferred embodiments of the present invention provides

a system that reduces the size and mass of apparatus required for sensing and

capturing vehicle data along the vehicle path such as a roadway. Also provided

in preferred embodiments are a convenient and secure device and method for processing sensed vehicle data and transmitting it to a central processing facility.

[0024] A preferred embodiment of the present inventive apparatus and

method is illustrated in FIG. 1, which illustrates a vehicle 2 travelling along a

path 4 and producing an emissions plume 6. An integral host device 10 includes apparatus for projecting a beam across the vehicle path and receiving the reflected

beam from a reflector across the path. When a vehicle has crossed the beam path,

emissions from the tailpipe 6 can be detected by appropriate optical systems and electronic circuitry within the host unit 10.

[0025] Also provided with the system may be a speed and acceleration

sensing system 12 and a video or other type of camera 14. The speed and acceleration sensor 12 may detect data regarding the speed and/or acceleration of

the vehicle as it passes, and the camera 14 may provide a picture of the vehicle

including its license plate.

[0026] In one embodiment, the speed and acceleration system 12 and camera 14 may communicate with the host 10 via wires 16 and 18 respectively. Alternatively, either or both of these units may communicate wirelessly via an

antenna 20 on the speed and acceleration system 12, and an antenna 22 on the camera 14, with an antenna 24 provided on the host unit 10. Thus, either or both

of the devices 12 and 14 may communicate by either a corded or wireless fashion

with the host unit 10.

[0027] The host unit 10 receives data regarding each passing vehicle,

which may include in the preferred embodiment speed and acceleration data,

video or other picture data of the vehicle, and data regarding the tailpipe emissions from the vehicle. Any of these three detection systems may be incorporated in as the host unit 10. In the illustrated embodiment, the emissions

sensor is incorporated with the host unit 10 in a common housing. In alternative embodiments, a system may be configured that only senses the speed of the

vehicle and records a picture of the vehicle, without sensing emissions. In such embodiments, the host unit 10 can be a separate unit or can be incorporated with the unit that senses speed and acceleration. In other embodiments, the host unit

10 might sense other vehicle data. Thus, although the host unit 10 is illustrated

in FIG. 1 as containing the emissions detection unit as well, the host unit 10 could

alternatively be incorporated with the speed and acceleration system 12, or the camera unit 14.

[0028] In a preferred embodiment, the host unit 10 receives the data

into a central processing unit 26, which may be an EBX platform computer, using a PC 104 or PC 104+ bus structure. This arrangement provides a desirable degree of compactness. However, any suitable CPU unit may be used.

[0029] In a preferred embodiment, the host system 10 records a log of

individual vehicle entries including sensed data. The log may also include user

input information and other information about the circumstances surrounding

each captured entry. The user can append the log with such information via any

of the external peripherals 30, 32, and 36 described below as part of a discussion

on FIG.2. The host 10 can then record this user input information in a log that may also include specific vehicle entries. In addition, the log can contain date

and time of recurrent events and activities conducted by the host, and contain

exception and problem events. Lastly, the log can contain date and time of when a user logged into and out of the host. All of this information is useful in the

validation of the data collected by the host.

[0030] FIG. 2 is a schematic view depicting a host and various data input and output devices, and other devices which may be utilized in preferred

embodiments of the invention. FIG. 3 is a schematic view depicting several

modes of communication that may be utilized between a host and various other

devices in preferred embodiments of the invention.

[0031] Before going into detail of FIG' s 2 and 3, it is fruitful to

review the Open Systems Interconnection (OSI) reference model for the networking of dissimilar hardware and software platforms. The OSI model

has been in existence since 1984, being produced by the International Standards Organization (ISO). There are seven layers to the OSI model as

listed in Table 1. Several portions of this embodiment cover different layers of

the OSI model and will be pointed out in the following text for the sake of

clarity, to distinguish at times from hardware and software innovations of this

embodiment. In general, all but the first layer are software in nature. Table 1: OSI Model

[0032] As described in more detail herein, and as shown in FIG. 2, a

wide variety of methods can be used (1) to input sensed data to the central

processing unit (FIG.l : 26); (2) to input instructions to the central processing unit

26, and (3) to retrieve vehicle-related and other data that has been stored by the

central processing unit 26. Any or all of these three functions can be achieved by using any or all of the various peripheral communication equipment described.

For example, as illustrated in FIG. 2, it is possible for an operator to visit the site and utilize a laptop computer 30 and/or a Personal Digital Assistant ("PDA") 32

to perform these functions on the unattended host 10. Typically, an operator may

use a PDA 32 or a laptop computer 30 to input instructions to the host 10 to

perform a given function. A list of some functions to be implemented by this

embodiment is listed in Table 2. The laptop computer 30 and/or PDA 32 can also

be used to display various information about the host 10, such as present

operational settings (System Information), vehicle emissions test information in real-time, and other functions. This provides an advantage of the invention,

whereby there is no need to provide a display or input keyboard on the host unit

10 itself. These devices can be linked into the host 10 either through an Ethernet connection, or through the preferred means of a wireless connection. A wireless

connection provides greater flexibility for the operator in checking the operational status of the system.

Table 2: List of Major and Minor Functions of Host

[0033] If the memory of the laptop 30 or PDA 32 is adequate, the

vehicle data records obtained from a sensing session may be transferred into the

laptop 30 and/or PDA 32 and then physically carried to a central processing

station where the data is downloaded and processed. [0034] In one preferred embodiment, the data can be downloaded onto

a high density storage drive system 34 associated with the laptop computer 30. Alternatively, a high density drive system 42 could be incorporated in the host

unit 10, with a removable memory element that is connected to the host 10 via an Integrated Drive Electronics (IDE), Small Computer System Interface (SCSI), PC

Card Type II adapter or Universal Serial Bus (USB) connection, then removed by the user to be taken to a central processing facility. In a preferred embodiment,

the drive 42 is a compactflash (CF+) Type II hard drive (e.g., IBM Microdrive

TM).

[0035] However, if host unit 10 is to be used in an environment not

conducive to removable media, the preferred embodiment is to omit the installation of a drive bay and connections for removable media within said host

10, and rely on the wireless transfer of data to an external device such as laptop 30 or PDA 32. The laptop 30 or PDA 32 can then have the removable media

capability in order to transport large volumes of data that the host system 10 is

capable of collecting. A ruggadized USB connection is also desired in these

harsh environment service areas where significant amount of road dust,

precipitation, and other elements preclude the utilization of open and exposed

computer-type contact surfaces. [0036] In addition to, or as an alternative to, the use of a laptop 30 or

a PDA 32, the host 10 on the laptop 30 or PDA 32 may be connected through the Internet via a Virtual Private Network ("VPN") to a desk top computer 35 a client/server relationship. A VPN is an example of a special implementation in

this embodiment of the fifth layer of the OSI Model (Table 1), and provides for

an added measure of security to the data, very important for utilizations of this embodiment that are used for enforcement of traffic and/or emissions laws. The

desktop computer 36 can perform the same functions as the laptop 30 or PDA 32, and in fact potentially run the same applications as the laptop 30 if desired. The

desktop computer 36 may be located in a remote central data processing facility,

or may be located at an intermediate location or even at the sensing site, or near the host 10.

[0037] In a preferred embodiment, "smart card" technology is used to enhance the security of the system. The host unit 10 may include a slot for

reading a smart card 38. Each of the other peripherals such as the laptop

computer 30, PDA 32 and/or the desktop computer 36 may also each have a smart

card reader.

[0038] The security levels by using different smart cards can be

segregated by "per user" and "per function" type of security. Smart cards can be

programmed with levels of security for different types of users such as for example, Auditor, Field Technician, Repair Technician, Engineer, and other types

of users and security levels commensurate with such users. Users can be

permitted to or prevented from accessing certain features and functions of the host unit 10 and associated commands and stored data. The same is true for

devices that may attempt a function that the device cannot support or should be prevented from even initiating a function. Given the programmable flexibility of

a smart card, per user validation can be set to expire, master site list can be periodically updated, and simple applets can be added, updated, and removed per

individual network requirements.

[0039] An additional feature of the preferred embodiment is that the

host unit 10 can communicate with, or incorporate a global positioning system ("GPS") receiver unit 40. One benefit of communicating with a GPS unit 40 is that the host unit 10 can record its location from many satellites orbiting the earth

so that data records taken at that location will include a precise identification of

the location. In addition, the GPS unit 40 provides date and time information via the GPS system. Accordingly, when a user first sets up the host 10 at a location,

the user can use the GPS unit 40 to provide location, date, and time information.

The GPS unit 40 may be a separate handheld device carried by the user, or in a

preferred embodiment, be provided by appropriate circuitry permanently installed

into the host unit 10. The smart card may also hold a master list of locations with coordinates for the locations of where the host may be located, in order to

compare GPS unit 40 data against expected coordinates - providing an added

measure of quality control.

[0040] Further, in some embodiments the host 10 also has the ability

to verify information (for example, where the host 10 has an internal GPS unit 40 that provides current date and time). In those embodiments the host 10 can

validate the date and time of peripherals such as laptop 30, PDA, 32, and desktop 36 when connected to ensure accuracy. That is, the host will synchronize, or

reset, the internal time of a peripheral with date and time information provided

by GPS unit 40 in the host 10.

[0041] FIG. 3 illustrates various modes of communication by which the host 10 may communicate with the various peripheral devices of FIG. 2, and ultimately with a central data server unit 50 in a central processing facility. One

way for such communication is for the host unit 10 to be connected directly, either by wire, wireless, or combination of wire and wireless connection, with the

central data server unit 50 via a VPN 52 over the Internet. This can be facilitated

if the host 10 is permanently or semi-permanently mounted on the side of a road

where testing of vehicles is desired. The central data server unit 50 will have

ninning on it a Structured Query Language (SQL) application, such as an Active

Data Object (ADO), to allow for acquisition of data from the remote host 10, as both the host 10 and the central data server unit 50 will have SQL-type databases

as opposed to a flat file structure. SQL databases allow for a much greater level

of security with the data not only from unauthorized use of the data, but also restrict access to certain data records and fields to avoid unintended modifications

to such fields.

[0042] Data residing on the host 10 as a result of one or more sensing

sessions will initially get replicated to the central data server unit 50 if a direct connection over a VPN 52 exists. If not a direct connection between host 10 and

central data server unit 50, then replication of the data occurs through

intermediate means such as suggested between the laptop 32 and the host 10, and then from the laptop 32 to the central data server unit 50. Replication is a concept

where data residing on the host is not immediately deleted when uploaded to the external peripheral 54 or server 50. For example, using the SQL command "Select" through an ADO object to glean data from the host 10 for all data rows

(records) that are within a range of specified date and time allows a

nondestructive query of the host 10 data, yet allows for the transfer of the data

obtained from the query. Raw data residing on the host 10 is not deleted until

final editing activities have been completed in the central data processing facility.

These data editing activities can include completing any records that are

incomplete, validation of the raw data, and archival of the data. This procedure of replication, retaining original (raw) data in the host 10 and copying the host

10 data to an external system 50 for processing on the external system 50, serves

to significantly reduce the possibility of loss of data due to corrupted data

fransmissions, corruption during the centralized data processing activities, or other calamity affecting the centralized data processing facility. It is not felt important to replicate data to more than just the central server 50 if employing the

intermediate step of using a laptop or other peripheral to transport data between

the host 10 and the central server 50. Procedurally, it is in the preferred embodiment to have the host 10 always retain raw data until instructed to delete

data (i.e. replication activities occur between the host 10 and central server 50,

with intermediate systems not required to hold transition data).

[0043] In addition, the host unit can send information and receive information using any of the "Blue Tooth: standard, jump-scanned wireless RF

frequencies, and/or infrared ("IRDA") communications. Each of these networking technologies is consistent with the lower layers of the OSI model as

seen in Table 1, and is of no concern to the upper layers of the model, part of the

beauty of the model. A given physical layer technology has greater or lesser

advantage depending upon the distance the wireless signal has to travel, the

number of wireless connections that exist between the host 10 and devices

(FIG.l : 12, 14) and/or peripherals (FIG.2: 30, 32, 36), collectively shown in FIG.3 as item 54, and whether there is a great need for secure transmissions of

data. For the sake of economy, a simple jump scanning RF technology is

preferred. If distances are close between the host 10 and devices and peripherals

54, an IRDA wireless method is suitable. For secure transactions among many devices and peripherals 54, the preferred embodiment would be to utilize Blue

Tooth technology. These networking hardware technologies can be mixed and matched within the embodiment of this invention if desired to meet combinations of need.

[0044] Management of wired or wireless connections between the host

10, external devices and peripherals 54, and central data server unit 50 is preferred to be handled through an in-vogue protocol such as Windows Sockets

(Winsock™) utilizing TCP/IP, primarily for the universal nature of Winsock (fourth and fifth layers of the OSI Model as listed in Table 1) being available in more than one programming language, and working across more than one

operating system. However, other networking programming interfaces may be

employed, particularly if a programming environment other than Microsoft Visual

Studio is chosen, and/or utilizing other networking protocols besides TCP/IP. For

instance, the host 10 can have Visual C++ applications running on a Windows

CE™ platform, the laptop 30 can have Visual BASIC applications running on

Windows 2000™, the central data server unit 50 can have Java applications/applets running on Windows 2000 Server™ which has a SQL server

application in the form of an ADO module or other means also running, and yet

the host 10 can interact with all systems seamlessly through Winsock.

[0045] This adds flexibility to the total data collection environment as

illustrated in FIG.3, by utilizing and adapting industry standard communications methods, protocols, and hardware implementations, along with allowing for

multiple operating systems for each peripheral; the rudiments of the OSI Model as applied to creating this embodiment. Flexibility of the embodiment is also

enhanced through the use of a common networking programming interface by

allowing applications (layer seven of OSI Model) written for the host 10, laptop

30, PDA 32, desktop computer 36, and the central server 50 to all be potentially written in different computer languages running on different platforms as exampled above, such that the best attributes of a given language and operating

system combination can be employed for the given hardware platform and operating system. The "best" combinations for host 10, each peripheral 54, and

central server 50 are dictated by the economics of computing hardware,

networking hardware and drivers, availability of software engineers with various

language skills, and costs to provide support and maintenance of the entire data

system. [0046] The architecture of FIG.4 is known as a 3-tier architecture to those skilled in the art of contemporary software design. Each tier has elements

that exist independently of elements within the tier and independently from elements in other tiers, and is a logical layout of how software components relate to each other, per lines connecting boxes within the architecture. The architecture

as illustrated in FIG.4 is meant to be a logical map and not a complete rendering of all specific routines within the hardware components that comprise the data

system of this embodiment. Nonetheless, there is sufficient detail for those

skilled in the art to see the application of 3-tier design into the preferred

embodiment.

[0047] An upper layer such as User tier 100 is where all of the user

interface applications exist. In this embodiment, the applications written in this tier are preferably written in Visual BASIC, which offers a broad amount of controls and services useful to present data to the user, provide controls for the

user to easily learn the means of operating the host (FIG.l : 10), and affords

simple and organized maintenance of the applications for future enhancement.

However, this language choice should not be limiting, as Java or other

programming languages can yield applications and scripts in an HTML document

that easily fulfill desired tasks of the user interface to the system, and therefore

can be one such alternative embodiment. Part of the criteria for selecting a computer language for User tier appUcations 132, 130, 136, 156 is the availabihty

of software engineers who can perform the coding efforts. Ideally, laptop 130 and

desktop 136 applications are the same, in the interest of reducing the software maintenance burden. However, PDA 132 applications are unique and limited to

the portability of computer instruction code to the processor-type in the PDA (FIG.2: 32). Additionally, the PDA 32 does not have the memory storage capabilities that a traditional laptop (FIG.2: 30) or desktop (FIG.2: 36) machines

have. For these reasons, PDA 132 applications are unique to the PDA 32.

[0048] A middle layer such as Business tier 110 has applications that

implement the needs of the business usage, that is collection of information about passing vehicles (FIG.l: 4), of the preferred embodiment. These applications can be whole routines or applets that implement a specific business function. For

example, there are routines embodied in the host (FIG.l : 10) that have no interface with users and do nothing but implement the collection of the data from

a passing vehicle, denoted as Data Record Assembler and Related Collection of

FIG.4 item 122. Other similar routines may physically reside within the host 10

and central data server unit (FIG.3: 50) provide specific functions that append

vehicle and related data to the databases of the host 126, but which do not have

interaction with the "outside world". These other routines within the Business

tier 110 implement data collection or data queries that are initiated by the user of the system or initiated by automated tasks queued into the system. The Business

tier 110 is the only means by which data can be acquired from the databases

shown in the Data tier 120. This provides for a consistency should there be a

need, after initial creation of the system, to revise a user application 132, 130, 136, 156, or a database 126, 150. A revised user application 132, 130, 136, 156 can replace prior versions of these applications without any impact to the

Business tier 110 applications or Data tier 120 databases, one of the main features of applying 3-tier software architecture design to this embodiment.

[0049] A lower layer such as Data tier 120 essentially contains

databases that are used by the system to permanently hold information of interest. While, for illustration purposes, only two databases are indicated in FIG.4 at the

Data tier 120, there can be nonetheless many databases contained within the physical hardware of the host 10 and central data server unit 50. Information

collected from a passing vehicle (FIG.l : 2), information about where the host 10 was set up for the data collection and a description of the path 4 that the vehicle

took when sampled, conditions under which the vehicle 2 was sampled, quality

assurance information, host 10 setup parameters, and other useful, pertinent data

can be stored in databases of items 126 and 150 within the Data tier 120.

[0050] Data initially collected in the field by the host 10 is considered

"raw" data, meaning it is unedited. Some pre-editing of the data can occur within the host 10, however it is not good practice to make changes to a raw database

without somehow retaining the raw data in the event that the raw data needs to

be restored. For this reason, the raw data is eventually and periodically replicated over to the central data server 150 database. It is in the central data server 150

database where all data editing is recommended. Data editing can be both a manual procedure, accomplished through one or more data processing

applications 156, or through an automated means by running one or more preprogrammed automated task in the form of a Business tier 110 central data

processing function 158. An example of a manual data editing task would be entering license plate information about the passing vehicle 2, except that in the

preferred embodiment, the method of editing is performed using components designed for a multi-tiered software architecture. An example of an automated data editing task would be to scan through many vehicle records of the central data server 156 database, looking for records that do not meet quality assurance

objectives and are therefore appropriately flagged in some means. The quality

assurance objectives can be preprogrammed into a Business tier 110 application

158 that is queued in the operating system of the centralized data server unit 50

once new raw data has arrived into the server database 150.

[0051 ] Should there be some sort of data disaster prior to completion

of editing tasks, the original raw data can be reacquired from the host data 126, by some direct means of query through a Business tier application 160. This is

assuming that there is a direct VPN connection (FIG.3: 52) between the host 10

and the central data server unit 50, or if not, by alerting a user to reacquire data through the path of a Business tier application 158 to a User tier application 156.

A user would then acquire the data from the host database 126 via one of several possible user interface means 132, 130, 136 to the host database 126, through a

business tier application designed for uploads and downloads of data 160.

[0052] While this indirect path of operation may seem cumbersome,

the fact is that software maintenance is greatly reduced by implementation of a

multi-tiered software architecture. This is primarily true because applications can be modified in any of the tiers and within tiers, without the modifications

affecting other applications or databases found within the system. For instance, it is of no consequence to the field user, and therefore user applications 132, 130,

136 with which the user interacts, if it is determined that a new quality assurance field is added to the central server database 156. In this instance, the only

changes heeded in the system are to the database 150 to provide for storage of the

new variable, modification to a Business tier application 158 to access the new

variable, and possibly to a centralized data processing application 156 that

updates or views the new variable. No other portions of the system are affected. [0053] A specific software architecture of the host (FIG.l: 10) is

shown in FIG.5. Several innovations have been applied to the host in order to integrate the functions of data collection with data inteφretation and data storage

all into one compact unit. Current art in the open-path on-road emissions testing field has only a data collection means out at the side of a road, peφendicular to the path (FIG1: 4) of vehicular traffic, and in the place of this embodiment's

integral host 10. This data collection means is tethered to a separate host computer located in a host vehicle also on the side of the road that gathers the

various data about a passing vehicle (FIG.l: 2) of which one of the data elements

is the measurement of emissions emanating from the vehicle's exhaust (FIG.l : 6), another element is the speed and acceleration measurement through some

means of measuring speed and acceleration (FIG.1: 12) of the vehicle 2, and still

another element is a video image of the vehicle 2 through some camera means (FIG.l: 14). Global position of the host 10 and correct date & time, both of

which collected from a GPS unit (FIG.2: 40), and weather data to record ambient conditions are not routinely gathered by current art systems. These additional

parameters contribute to improved quality assurance of the emissions data

collected, as corrections to the emissions measurement back to standard

temperature and pressure can be made. Variability of time keeping by a host

system 10 can cause the entire dataset not to be trusted, particularly if the time drift is significant. A preferred embodiment however includes collection of this

additional data, through an integrated means within the data collection means,

which has been referred to as "host" throughout this description.

[0054] One major challenge in integrating the data collection with data

inteφretation and data storage into one computing system utilizing one

microprocessor is that vehicles travel the testing path 4 at speeds from 20-100 kilometers per hour, thereby not allowing much time for the emissions test to take place. This emissions testing must occur in real-time, not being put off as a task

in a queue to the processor of a data collection device for eventual execution.

Couple this with the fact that an image of the vehicle needs to be captured prior

to the vehicle 2 disappearing out of view are reasons that contribute to the current state of the art having a dedicated processor unit collect emissions data out at the roadway and send the data by wired cable means to a separate host computer that can assemble all the emissions, speed and acceleration, and video image data.

The separate host computer, usually located in a host vehicle such as a van, does

not have such an intensive real-time data collection requirement, as a data record

can be assembled at anytime after the data event of a vehicle passing, though not

without some risks of sequence misalignment of data elements from various

sources of data. Furthermore, current computer operating systems from Microsoft

do not normally allow for real-time data access, yet it is desired to use Microsoft products as part of systems integration due to the large numbers of software

engineers who can work with Microsoft products, in comparison to those skilled

with products of other vendors.

[0055] However, one preferred embodiment of this invention is to

nonetheless integrate all of the functions of data collection, inteφretation, and storage into one host unit that also contains the emissions testing means, obviating any separate host computer and supporting hardware and vehicle to

gather data from all sources, inteφret same, and store for later retrieval, while

using Microsoft operating systems and Visual Studio developed products. The

usage of Microsoft products provides a large labor pool of software engineers already skilled in coding and porting applications that are running on a Microsoft

operating system platform. Furthermore, the ubiquitous availability of Microsoft operating systems and language products provides for an economy when purchasing supporting products used to produce the embodiment. Many

commercially available items of computing hardware already have Microsoft

operating system drivers that link the hardware to the software, thus saving

valuable coding efforts for integrating systems to work together and not having

to additionally expend resources developing driver code.

[0056] This is not to be concluded that a preferred embodiment must

be coded to run on a Microsoft platform. Linux and other operating systems have desirable characteristics that lend themselves well to fulfilling the tasks of an

integrated host system, including multitasking, multithreaded, preemptive

abilities to run real-time applications and routines of higher priority over lesser priority tasks, SQL-compatible databases, simpler driver development (though drivers will most likely require development for these other systems), and coding in languages such as C, Java, and other contemporary languages, providing

something of a labor pool of software engineers who could adapt to the differences between Microsoft products and others. However, for the puφoses

of simplicity of discussion, this description will use terms normally reserved for

Microsoft products when reviewing the elements of FIG.5. Persons skilled in the

art of software development can appreciate that there are features of other operating systems and programming environments that are analogous to the terms used in this description.

[0057] Each of the boxes represented within the Business tier 210 can

be Component Object Model (COM) objects that are instantiated by the main program of the host, or can be threads of varying priority created by the main

program. COM objects lend very well to a multi-tiered software architecture, in

that they are essentially external routines to an application, and as such, can be

compiled independently with new features if desired, without the application

itself requiring recompilation. This is a distinct advantage over any existing art that has all features and functions of a system compiled into perhaps only one

application or project for each device in the system. Future software maintenance

of the preferred embodiment host system is simplified, as there is no need to create and maintain a legacy archive of all previous versions of applications and

code that comprises those applications. By nature of a COM object as defined by

Microsoft, a software engineer who creates or inherits the code of a COM object must maintain the interface of the COM object throughout all iterations of code revisions to the COM object, in order for legacy and subsequently new

applications to be able to use newer versions of the COM object. While the

interface to the COM object is the same, the inner workings of the COM object

can be revised, even radically, without the application ever "realizing" that a change has been made. Furthermore, new properties and functions can be added to a COM object without any changes made to the interface.

[0058] A special variant of COM, known as DCOM for Distributed

Component Object Model, allows COM objects to be located in a physical

machine outside of the machine that is running a given application. For instance,

the host 10 can have a DCOM object within its memory that is available to, and

possibly even be required for proper function execution by, an external peripheral

such as the laptop (FIG.2: 30) or other peripheral, provided that applications on

the peripheral have the requisite software and configuration to run a DCOM object. This feature, similar to that of a resident COM object, allows for

simplified and reduced software maintenance requirements of a system, as legacy

applications can run newer versions of DCOM objects that may reside in a machine that is more convenient for updating by network administrators. There

is also an added measure of security with DCOM objects utilization, as it is harder for a feature to be used to "hack" into a host, if the offending external

peripheral does not have the capability to run, or does not know the existence or need for the ability to run a DCOM object in order to properly interface with the

host 10 (security through obscurity).

[0059] As stated above, FIG.5 illustrates a preferred 3-tier software

architecture for integrating the functions of data collection, inteφretation, and

storage all into one host unit (FIG.l: 10) that also at a minimum collects emissions information from vehicles that pass the host. To allow for said

integrated host 10 to operate unattended and without requiring any separate

supporting computer and vehicle, the user interface is through either a wired means such as through a serial port or USB connection, or through the preferred

means of a wireless connection. Applications that run on external peripherals that

can interface with the integrated host 10 include a laptop, also known as notebook

computer 230, a PDA 232, and desktop computer applications 236. None of

these applications have a direct impact on the applications of the integral host, and therefore can be revised independently of the software of the host 10 as

illustrated in FIG.4. The preferred link between these applications and the host

applications follows the OSI Model as previously discussed, with Winsock

utilizing TCP/IP providing the communications means between the peripheral user interface and the host 10, however other suitable links and networking

protocols may be implemented.

[0060] All user commands from the peripheral come into the host 10

through a command inteφreter object 260 running in the Business tier 210 of the

3-tier architecture. This Command Inteφreter 260 is preferred to be a COM

object, however could easily be a thread of the main program of the host 10. The

Command Inteφreter 260 will verify a given command against security clearance, done through the Security Manager object 262 to execute that command. A list of suggested commands to be used by the host are listed in Table 3. Assuming

security clearance has been granted, the Command Inteφreter 260 then processes the command as appropriate, usually by, depending upon the extent of the needs

in executing the command, send the command off to a module dedicated to

accomplish that task, send command to a Main routine 264 of the host

application, or executing the command directly. For example, the received

command may be to set the mode of the host into a data collection mode. Data

collection mode is defined as collect data from emissions, speed and acceleration, camera, GPS, and weather systems upon the presence of a vehicle (FIG.l : 2)

breaking the sample path which is roughly peφendicular to the path of the vehicle

(FIG.l : 4), inteφret the emissions of the vehicle by applying Beer-Lambert Law

or other suitable method and applying a combustion equation to correct for dilution of the exhaust emissions (FIG.l : 6), then logically store the resulting data

obtained from all of the sources of data available as mentioned above.

Table 3: Command Set for Integral Host

[0061] Physical collection of raw data is represented in the Data tier

220 of FIG. 5 by devices interfaced into the host 10 through COM objects

collectively referred to as item 266. Various databases exist in this tier that

provide operating parameters of the integral host 10 including but not limited to

"permanent" setup parameters of devices contained within the host 10 (if the

system registry is not used for this puφose), calibration information, monitoring site information, and other data elements that are routinely referenced by the host

system 10 but not normally user accessible or otherwise changeable data.

Additionally, there are databases that reserve space for storage of data collected about the vehicles that have passed by the system.

[0062] Data collection devices each preferably have a COM object 266 associated with the respective device. A COM object is preferred over utilization

of an integrated thread within the main application of the host 10, as future versions of the host 10 may use different device hardware to deliver a data stream

of specific information. For example, there are several manufacturers of weather

collection data equipment. If a COM object 266 is used as a means for a host application to collect weather data, future versions of the weather COM object

266 could be made to interface with more than one manufacturer's equipment and

be loaded into the host memory, without ever having to recompile the Business tier 210 application that periodically requests data from the weather device, in this

case denoted as item 268 of FIG.5. This newer version of the COM object 266

can also allow legacy host systems to be retrofitted with weather data gathering

equipment from any of several vendors without any need for updating the version

of the application 268 in the host that periodically requests weather data.

[0063] In a preferred embodiment, there is one COM object 268 in the

Business tier 210 that collects all of the data from COM objects 266 associated with various data gathering devices. This data is then assembled into dynamic

arrays of a particular data class and passed off to a Data Processor object 270.

The Data Processor object 270 for example takes raw emissions data and

calculates emissions measurements based on optical absoφtion, corrects the measurement to Standard Temperature & Pressure (STP), and runs these

emissions measurements through a combustion equation to correct for dilution of exhaust (FIG.1 : 6) from the tested vehicle. Additional processing can take

place within this Data Processing object 270 that will take raw measurements

from any data source and calculate and/or convert the data into something useable.

[0064] Processed data from the Data Processor object 270 is then sent to a Data Manager object 225 that eventually commits the data to permanent

storage. Because of the need for the host's processor (FIG.l : 26) to devote virtual real-time attention to emissions measurements, COM objects 266 the gather time-

critical information about a passing vehicle 2 are generally set at a high priority.

The data storage object 225 can be set to run at a much lower priority to

minimally intrude on processor time, as it is not as time critical to commit data

to permanent storage so long as data is eventually committed to such permanent

storage 226. [0065] For illustration brevity sake, all databases and tables contained

within them are represented in FIG.5 as item 226. The physical structure of the

host databases is such that a Business tier 210 application 225 is associated with a database to be consistent with the structure of a 3-tiered software architecture.

Normalization of the tables of databases is accomplished well before the construction of such databases. This normalization is preferably optimized for

the speed of operation of the system, which may lead to a somewhat space inefficient layout. However, it is not necessary to optimize for speed, as it is

possible to optimize database normalization for other desired effects, such as

reduced size of the database and/or tables therein for faster data transfers.

[0066] As described herein, the embodiments of the present invention can provide an integral host unit that is self-contained during vehicle data sensing sessions and does not require a van or operator to be present during data capture.

The invention also provides embodiments that provide secure and convenient

retrieval of data and control of the unit. Furthermore, a software architecture has

been disclosed that enables such integral host unit to accomplish the tasks that

hardware of an integral host system is desired to accomplish in measuring

information about passing vehicles.

[0067] The many features and advantages of the invention are apparent

from the detailed specification, and thus, it is intended by the appended claims to cover all such features and advantages of the invention which fall within the true

spirits and scope of the invention. Further, since numerous modifications and

variations will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation illustrated and described, and

accordingly, all suitable modifications and equivalents may be resorted to, falling within the scope of the invention.

Claims

What is claimed is:

1. A device that senses emissions from a vehicle comprising:

a user information interface, said user interface being a part of an upper layer;

a detector that detects information about a vehicle, said detector in communication with said user information interface and being a part of a lower layer;

a processor in communication with the detector to receive the

information from said detector and process the information, said processor

being a part of a middle layer; and

a storage device that stores the information, said storage device in communication with said processor and being a part of said lower layer.

2. The device as recited in claim 1 wherein said middle layer comprises modules for processing the information wherein each module is a

thread of varying priority.

3. The device as recited in claim 2 wherein one of said modules is

a Component Object Model.

4. The device as recited in claim 2 wherein one of said modules is

a Distributed Component Object Model.

5. The device as recited in claim 2, wherein modules that are

identified as having a higher priority will be processed before other modules identified as having a lower priority.

6. The device as recited in claim 1 wherein said middle layer

comprises a security system that prevents unauthorized access to the information.

7. The device as recited in claim 6 wherein said security system is within a Structured Query Language application.

8. The device as recited in claim 6 wherein said security system

uses a smart card security validation system.

9. The device as recited in claim 1 wherein said middle layer

comprises a replicator application that copies the information to an external

device before the information is processed.

10. The device as recited in claim 1 wherein said lower layer

comprises a Structured Query Language accessible database to store the

information.

11. The device as recited in claim 10 wherein said database is

normalized for efficiency.

12. A method for sensing emissions from a vehicle comprising the

steps of:

detecting information about a vehicle in a lower layer; storing the information in said lower layer;

processing the information in a middle layer; and making the information available to users in an upper layer.

13. The method as recited in claim 12 wherein said processing step

further comprises the step of processing the information with modules wherein

each module is a thread of varying priority.

14. The method as recited in claim 13 wherein at least one of said

modules follows a Component Object Model paradigm.

15. The method as recited in claim 13 wherein at least one of said

modules follows a Distributed Component Object Model paradigm.

16. The method as recited in claim 13, wherein said processing step

further comprises the step of executing modules identified as having a higher priority before other modules identified as having a lower priority.

17. The method as recited in claim 12 wherein said processing step

comprises the step of preventing unauthorized access to the information.

18. The method as recited in claim 12 wherein said processing step comprises the step of using Structured Query Language through an Active

Data Object paradigm.

19. The method as recited in claim 12 wherein said processing step

comprises the step of preventing unauthorized access using a smart card

security validation system.

20. The method as recited in claim 12 wherein said step of storing further comprises the step of externally replicating the information from the

lower layer before the information is processed, and further processing the

replicated data externally.

21. The method as recited in claim 12 wherein said step of storing comprises the step of storing the information in a Structured Query Language

accessible database.

22. The method as recited in claim 21 wherein said step of storing

further comprises the step of normalizing the database for efficiency.

23. A system for sensing emissions from a vehicle comprising the

steps of: a means for detecting information about a vehicle in a lower

layer; a means for storing the information in a lower layer; a means for

processing the information in a middle layer; and

a means for making the information available to users in an

upper layer.

24. The system as recited in claim 23 wherein said means for processing further comprises a temporary memory means for containing

executable code and the information to be processed, with executable code

organized in modules wherein each module is a thread of varying priority.

25. The system as recited in claim 24 wherein at least one of said modules is a reusable object in memory that has a common interface to other

modules that use the object.

26. The system as recited in claim 24 wherein at least one of said

modules is a reusable object in memory that can execute code from modules in

external devices.

27. The system as recited in claim 24, wherein said means for processing further comprises a means for executing modules identified as

having a higher priority before other modules identified as having a lower

priority.

28. The system as recited in claim 23 wherein said means for

processing comprises a means for preventing unauthorized access to the

information.

29. The system as recited in claim 23 wherein said means for

processing comprises a means for using a Structured Query Language constructs for processing the information.

30. The system as recited in claim 23 wherein said means for

processing comprises a means for using a smart card security system for information access validation.

31. The system as recited in claim 23 wherein said means for

storing further comprises a means for replicating the information from the lower layer before the information is processed externally.

32. The system as recited in claim 23 wherein said means for

storing comprises a means for storing the information in a Structured Query

Language accessible database.

33. The system as recited in claim 32 wherein said means for

storing further comprises a means for normalizing the database for efficiency.

34. A system for processing sensed vehicle data, comprising:

a sensor for sensing data related to at least one characteristic of a

passing vehicle; and a host unit that receives sensed data from the sensor.

35. A system according to claim 34, wherein the sensor and the host unit are integrated into a single housing.

36. A system according to claim 34, wherein the sensor is a vehicle

emissions sensor.

37. A system according to claim 34, wherein the sensor is a vehicle speed sensor.

38. A system according to claim 34, wherein the sensor is a camera.

39. A system according to claim 34, wherein the system updates an

internal events log.

40. A system according to claim 34, further comprising a peripheral

communication device, wherein the peripheral communication device and the host unit communicate with each other to transfer at least one of sensed

vehicle data and commands between the host unit and the peripheral

communication device.

41. A system according to claim 40, wherein the host includes a

memory for storing sensed vehicle data.

42. A system according to claim 40, wherein the peripheral

communication device is a laptop computer.

43. A system according to claim 40, wherein the peripheral

communication device is a Personal Digital Assistant.

44. A system according to claim 40, wherein the peripheral commumcation device is a desktop computer.

45. A system according to claim 40. wherein peripheral

commumcation devices are date and time synchronized to the host unit's date

and time.

46. A system according to claim 34, wherein the host comprises a

smart card reader.

47. A system according to claim 40, wherein the peripheral communication device comprises a smart card reader.

48. A system according to claim 40, wherein the peripheral communication device transfers data to a central processing facility.

49. A system according to claim 34, wherein the host

communicates with the peripheral communication device via infrared signal.

50. A system according to claim 34, wherein the host

communication with the peripheral communication device using an internet

connection.

51. A system according to claim 34, wherein the host

commumcates with the peripheral commumcation device using wireless RF

frequency.

52. A system according to claim 34, wherein the host

communicates with the peripheral device via the Blue Tooth™ standard.

53. A system according to claim 34, wherein the host communicates with the peripheral device using a Virtual Private Network over

the Internet.

54. A system according to claim 34, wherein the host transfers data

to central processing facility.

55. A system according to claim 54, wherein in the host communicates with the central processing facility using a Virtual Private

Network over the Internet.

56. A system according to claim 34, wherein the host includes a

removable nonvolatile memory media and stores sensed vehicle data on the

removable nonvolatile memory media.

57. A system for processing sensed vehicle data, comprising:

means for sensing data related to at least one characteristic of a

passing vehicle; and means for receiving sensed data from the sensor and storing

said sensed data, wherein the sensor and host are integrated into a single housing.

58. A method for processing sensed vehicle data, comprising the steps of: sensing data related to at least one characteristic of a passing

vehicle;

receiving and storing the sensed data with a host unit that is

integrated into a single housing together with the sensor; and

appending events into an electronic log that includes a date and time stamp of when an event occurred.

59. A method according to claim 58, further comprising the step of

communicating between the host and a peripheral device, wherein the

peripheral device comprises at least one of a laptop computer, a Personal Data

Assistant, and a desktop computer.