Patent Grant
11577689
Traditional response vehicles include various features and systems for assisting an operator of the response vehicle in responding to an incident. Such systems may provide navigation assistance, warning lights, and incident information. Operators are traditionally not able to wirelessly connect with an interface of the response vehicle, thereby preventing the operator from viewing information relating to the response vehicle and incident on a user device.
One embodiment relates to a response vehicle. The response vehicle includes a transmission, a braking subsystem, and a vehicle management system coupled to at least one of the transmission and the braking subsystem. The vehicle management system includes an interlock module configured to provide a signal to switch the at least one of the transmission and the braking subsystem from a locked condition to an operational condition only in response to an authenticated user request thereby preventing undesired operation of the response vehicle.
Another embodiment relates to a response vehicle management system. The response vehicle management system includes a vehicle subsystem, a sensor, a transceiver, and a processing circuit. The vehicle subsystem includes at least one of a command system, a siren, a lighting system, a generator, a water pump system, a foam system, a water tank, a foam tank, a fuel tank, and a governor. The sensor is configured to monitor the vehicle subsystem and provide a sensor signal corresponding thereto. The processing circuit is coupled to the sensor and the transceiver. The processing circuit is configured to: (a) evaluate data relating to the vehicle subsystem based on the sensor signal and (b) provide the data for transmission by the transceiver in response to an authenticated user request
Still another embodiment relates to a response vehicle control system. The response vehicle control system includes a response vehicle having a vehicle subsystem, a transceiver, and a processing circuit. The vehicle subsystem includes at least one of a command system, a siren, a lighting system, a generator, a water pump system, a foam system, and a governor. The processing circuit is coupled to the transceiver and configured to: (a) evaluate an access level of a user; (b) provide user interface data for transmission by the transceiver; (c) evaluate an authenticated command provided by the user; and (d) provide a control signal to the vehicle subsystem in response to the authenticated command, wherein the user interface data provided by the processing circuit varies based on the access level of the user thereby preventing unauthorized control of the response vehicle.
Another embodiment relates to a vehicle management system that includes a display module, a first user device coupled to the display module with a direct Wi-Fi connection, and a second user device coupled to the display module with the direct Wi-Fi connection. The display module is configured to store user interface data onboard the vehicle and provide the user interface data to the first user device and the second user device in response to a user request. The user interface data provided to the first user device and the second user device varies based on an access level of the user.
Still another embodiment relates to a response vehicle that includes a communications interface and a vehicle management system having an onboard communications module. The communications interface is configured to receive an incident signal from at least one of a mobile device and another response vehicle, and the onboard communications module includes a repeater module configured receive the incident signal and provide a relayed signal, thereby extending a transmission of the incident signal.
The invention is capable of other embodiments and of being carried out in various ways. Alternative exemplary embodiments relate to other features and combinations of features.
The disclosure will become more fully understood from the following detailed description, taken in conjunction with the accompanying figures, wherein like reference numerals refer to like elements, in which:
Before turning to the figures, which illustrate the exemplary embodiments in detail, it should be understood that the present application is not limited to the details or methodology set forth in the description or illustrated in the figures. It should also be understood that the terminology is for the purpose of description only and should not be regarded as limiting.
Systems and methods are described herein for providing various features as part of a response vehicle management system. More particularly, systems and methods are described for providing a response vehicle control and monitoring system. The response vehicle control and monitoring system includes a transceiver onboard the response vehicle configured to interface with a mobile device (e.g., a smartphone, tablet, laptop, etc.). The transceiver facilitates communication between the systems of the response vehicle and the mobile device, facilitating user control and monitoring of an incident and/or the response vehicle. The transceiver may interface with, for example, the drivetrain, command system, sirens, lighting, generators, and/or governors of the response vehicle. A user may monitor the health of the response vehicle, confirm that its systems are operating within normal parameters, and retrieve (e.g., view, download, etc.) vehicle diagnostics.
The user device may receive information from the response vehicle that is stored onboard the vehicle. The information may be provided as a webpage on the user device, eliminating the need for the user to download an application to interface with the response vehicle and allowing the user interface to be used across different user devices (e.g., on different platforms, on devices with different operating systems, etc.). The webpage content may be stored onboard the response vehicle.
In one embodiment, the communications system facilitates localized wireless communication between various response vehicles and other devices. For example, several response vehicles may respond to an incident and be spread out over a wide area around the incident. The communications systems of one response vehicle may facilitate communications with other, surrounding response vehicles and/or user devices. For example, a commander may be within wireless range of one response vehicle but not the other response vehicles. The communications systems of the response vehicles may act as repeaters, allowing the commander to communicate with each of the response vehicles, even those that are out of range of the commander's mobile device.
In one embodiment, the user devices communicate with the response vehicles via Wi-Fi. In other embodiments, the communications between the user devices and/or response vehicles may be supported via CDMA, GSM, or another cellular connection. In still other embodiments, another wireless protocol is utilized (e.g., Bluetooth, Zigbee, radio, etc.).
Referring to
Vehicle 100 includes an onboard communications device 106 for transmitting and receiving data via a wireless connection. Communications device 106 facilitates wireless communication with various user devices and/or other vehicles 100. For example, communications device 106 may transmit response vehicle information to a user device of an occupant of the vehicle, to a commander on site at an incident, and/or to a system or person positioned remotely relative to an incident. Further, communications device 106 may facilitate transmissions between multiple response vehicles. In one embodiment, communications device 106 at least one of includes and acts as a repeater, facilitating transmission of signals from another source (e.g., a commander user device, etc.) to a device or response vehicle out of range of the original source.
While vehicle 100 is shown as a fire truck, it should be understood that the systems and methods disclosed herein are applicable to an ambulance, a police vehicle, a tow truck, a public utility vehicle, a municipal vehicle, a military vehicle, a lift device, or any other type of response vehicle or other vehicle. Further, the systems and methods disclosed herein may be applicable for any type of incident, scene, or site in which wireless communications between one or more vehicles and user devices is advantageous.
Referring to
One or more of the response vehicles 204, 206, 208 may include an onboard communications device 106 facilitating communications between the response vehicles and user devices. For example, a response vehicle may be in range of one or more personnel 212 on site at incident 210, and may transmit information to and receive information from personnel user devices (e.g., mobile devices, etc.).
In one embodiment, the onboard communication devices of the response vehicles at least one of include and act as repeaters. For example, some response vehicles (e.g., response vehicle 208, etc.) may be out of the range of the user device of commander 202. The onboard communication device of response vehicle 204 may include or act as a repeater. Upon receiving a transmission from a user device of commander 202, the onboard communications device of response vehicle 204 may relay the transmission to response vehicles 206, 208. Response vehicles 206, 208 may then provide the transmission to personnel 212 in range, evaluate a vehicle or vehicle system command specified in the transmission, and/or perform still another task.
Similarly, since some response vehicles may be outside of the range of commander 202, the onboard communications device of response vehicle 204 may be used as a repeater to relay transmissions from the out of range response vehicles (e.g., vehicle 208, etc.) or personnel to a user device of commander 202. For example, response vehicle 204 may relay status information, warnings, and other information to commander 202 from response vehicle 208. Such communication may allow commander 202 to more effectively manage personnel and equipment on site.
In one embodiment, the information relayed between commander 202, personnel 212, and response vehicles 204, 206, 208 includes status information for the response vehicle. Status information may include, for example, general vehicle diagnostic activity (e.g., if fuel is low, if oil is low, other general vehicle-related errors, etc.), or information regarding various vehicle subsystems (e.g., water tank levels, pump operation, warning lights, sirens, navigation system, etc.). The information may be displayed on one or both of a display provided as part of the response vehicle and on a user device of commander 202 and/or personnel 212. In one embodiment, the information is transmitted to a user device and displayed on the user device in a webpage format. This information may be retrieved by the response vehicle from vehicle subsystems. For example, the information may be retrieved in real-time or near real-time as the vehicle is in operation (e.g., the vehicle is being driven or actively used in response to an incident, etc.). The commander may then use the information to manage use of the response vehicles at the incident. As another example, the information may be retrieved from vehicle subsystems in between incidents.
Referring now to
In one embodiment, response vehicle 100, and more particularly vehicle management system 300, is configured to wirelessly communicate with a plurality of other response vehicles 350, user devices 352, and/or at least one commander device 354. As described above with reference to
In some embodiments, as shown in
As shown in
As shown in
As shown in
In one embodiment, diagnostics module 322 identifies an error or fault associated with the response vehicle based on telemetry data. The error or fault may be a specific error or fault instead of a generic warning. For example, instead of displaying a “check engine” light on a display of the response vehicle, a more specific fault message may be displayed that allows a user to more quickly diagnose and repair the problem. The fault message may be displayed on a display unit 340 of the response vehicle and/or on a user device 352 (e.g., transmitted to the user device by communications interface 302, etc.). Diagnostics module 322 is described in greater detail below with reference to
As shown in
As shown in
As shown in
The data may be removed from database 328 once the data is uploaded from the local database to a remote cloud storage. For example, long-term storage of the telemetry data and other data may be done on a centralized server 358, and communications interface 302 may wirelessly connect with remote server 358 to transmit and store the data. As described above, the data includes a timestamp and vehicle identifier information to identify the data in remote server 358. Data may be stored in database 328 until transmission to remote server 358. The data may be kept in database 328 to allow for a “snapshot” view of the data on a user device (i.e., once the data is captured, the data may be provided shortly thereafter to user devices near the scene of an incident, etc.).
In one embodiment, the data is automatically updated periodically. The data may also be updated upon user request. A controller area network (CAN) controller, such as diagnostics module 322 or another module may be configured to monitor the data and to determine when a potential status of the response vehicle 100 has changed based on the telemetry data changes.
Database 328 may be any type of database (e.g., a SQLite database, etc.), and diagnostics module 322 may query the database using any type of language or method via backend framework. The backend framework of vehicle management system 300 may support the activities of periodically updating and querying database 328, as well as providing web layer authentication (e.g., to authenticate devices that attempt to access data from database 328, etc.). The backend framework may further support the various security-related functionality of onboard communications module 320.
Vehicle management system 300 may include, for example, a data transport protocol layer configured to facilitate the query of data from database 328 for use by the various modules of memory 308. In one embodiment, at least one of web sockets and AJAX polling is used to invoke queries via backend framework and provide the data to the frontend applications (e.g., the application layer, the modules, etc.), as they allow changes to database 328 to be detected and pushed to the application layer. The use of web sockets and/or AJAX may be based on compatibility constraints and performance constraints with the user devices 352 accessing vehicle management system 300. The application layer, or the frontend application, of vehicle management system 300 may be built using, for example, HTML5, CSS, and various Javascript libraries.
As shown in
The interlock module 330 may be configured to facilitate activating one or more interlocks that prevent the response vehicle and/or components thereof (e.g., water pump, foam system, sirens, lights, etc.) from being operated by an unauthorized user. For example, when arriving at a scene of an incident, an operator of the response vehicle 100 may be able to enter the response vehicle into a “scene mode” or “lock mode” using one or more commands (e.g., a user request, etc.) on the display unit 340, the user device 352 (e.g., a wireless control interface, etc.), the commander device 354 (e.g., a wireless control interface, etc.), and/or other input devices of the response vehicle 100 (e.g., switches, dials, toggles, parking brake, etc.). In some embodiments, interlock module 330 is configured to engage a parking brake and/or lock a transmission of the response vehicle 100 when the scene mode is activated. In other embodiments, the interlock module 330 is configured to activate the scene mode in response to the parking brake being activated (e.g., engaged, etc.) by an operator of the response vehicle 100. In still other embodiments, the interlock module 330 is configured to automatically enter the scene mode based on an indication relating to the response vehicle 100 arriving at a scene and/or automatically based on an indication relating to the presence of an operator (e.g., the lack of the presence of an operator, an operator exiting the response vehicle 100, an operator opening the door of the response vehicle 100, etc.). According to an exemplary embodiment, the interlock module 330 is configured to facilitate operation of at least one of an engine, a generator, a pump, a foam system, a water system, a siren, a lighting system, etc. while in the scene mode. According to an exemplary embodiment, such as system controlled by the interlock module 330 does not require modification to Federal Motor Vehicle Safety Standards (“FMVSS”) brake circuit control of parking brakes.
According to an exemplary embodiment, activating the scene mode prevents an operator from shifting the transmission of the response vehicle 100 from a locked condition (e.g., corresponding to a parking gear, etc.) to an operational condition (e.g., out of park, corresponding to a drive gear and/or a neutral gear, etc.) and/or releasing the brakes (e.g., switching from an engaged configuration that limits movement of the response vehicle 100 to a disengaged configuration that does not limit movement of the response vehicle 100, etc.). For example, the interlock module 330 may lock the transmission and/or the brakes such that the response vehicle 100 may not be moved by an unauthorized user. To move the response vehicle 100 and/or deactivate the scene mode, the interlock module 330 may require a user to enter an access code (e.g., username, ID, password, on the display unit 340, on the user device 352, on the commander device 354, etc.) and/or perform a series of actions (e.g., activate and/or deactivate a series of switches and/or buttons, a fingerprint scan, a facial recognition scan, a retinal scan, etc.) to verify the user has permission to move the response vehicle 100. Once the user is verified, the interlock module 330 is configured to disengage the locks on the brakes and/or the transmission to allow the user to move the response vehicle 100.
According to an exemplary embodiment, activating the scene mode prevents the response vehicle 100 from rolling or otherwise moving in response to intentional and/or unintentional disengagement of the parking brake or other brakes without the user verifying permission and/or access to do so. For example, an accidental disengagement of the parking brake may allow the response vehicle 100 to unintentionally begin to roll (e.g., if parked on a slope, if the transmission is in neutral, etc.). However, the interlock module 330 keeps the brakes engaged and/or the transmission locked until the scene mode is deactivated (e.g., by a user entering an appropriate access code, performing a series of actions, etc.) to prevent such unintended movement of the response vehicle 100.
While vehicle management system 300 is described in
Referring now to
Onboard communications module 320 may include a HTTPS security layer 408 configured to encrypt transmissions from the response vehicle using a local SSL certificate (e.g., to put the transmission under HTTPS instead of HTTP, etc.). Onboard communications module 320 may include a web authentication layer 410 configured to prevent unauthorized access. For example, even if a hacker or attacker accesses the communications from onboard communications module 320, he/she would still need a username and password (or other identification information) to read and/or change any data. Usernames, passwords, and other identification information may be provided via a separate interface from communications interface 302 and then used on the network supporting onboard communications module 320 communications. In one embodiment, a long term cookie may be set upon a successful authentication of a user device, which may be updated with timestamp information as the user continues to access the network shared with onboard communications module 320. Using the identification information, user devices may be given an appropriate permission level. For example, some user devices might have read-only access to data provided by the response vehicle, while other users may have read-write access (e.g., a commander, etc.). As another example, onboard communications module 320 may track who is currently in communication with the response vehicle, and may be configured to account for multiple people having read-write access (e.g., allowing only one user device at a time to have read-write access to the data, etc.). Different user interfaces (e.g., webpages, etc.) may be provided based on an access level of the user.
As shown in
An administrator may be able to configure and provision field device access. For example, when responding to an incident, the administrator may manage which devices have access to which information. In other words, those in the administrator group may be able to act as a commander at an incident. Administrators may generally be able to add, modify, and/or delete device level user accounts, view reports of telemetry data and other data, control one or more features of the response vehicle, and update device software and apply firmware patches manually as needed.
A responder (e.g., a policeman, a firefighter, etc.) may be a user in the field responding to an incident. The responder group may be created for users who have access to the network via a pre-authenticated device and/or user account. The responder may have to enter (or have previously entered) credentials specific to the user account to access the network. The responder may be able to view telemetry data and manually control various onboard systems of the response vehicle (e.g., a subset of features of the response vehicle, etc.).
Onboard communications module 320 may include a telemetry data module 414 configured to analyze telemetry data relating to the transmissions over a network between response vehicles and user devices. Telemetry data may generally refer to metrics relating to the transmission of signals to and from the response vehicle. The response vehicle 100 may include any number of sensors 344 configured to record telemetry data for use by onboard communications module 320. The telemetry data may be used to analyze the network performance of a Wi-Fi network local to the response vehicle on site at an incident. The telemetry data may be used to determine which devices and vehicles are capable of communicating with one another and facilitating connections to allow the devices and vehicles to communicate with one another.
Onboard communications module 320 may include a repeater module 416. Repeater module 416 may facilitate the operation of onboard communications module 320 as a repeater at the scene of an incident. Referring again to
In some embodiments, the communications module of response vehicle 204 includes or acts as a repeater (e.g., thereby allowing commander 202 to communicate with the out-of-range response vehicles, etc.). Commander 202 may thereby view the status of, command, and/or otherwise communicate with each of the response vehicles at the site. For example, the commander may be provided with data relating to the status of every response vehicle (e.g., to see if any response vehicle has a fault, is breaking down, is running low on fuel, etc.). Since the range of Wi-Fi communications may be limited at the incident site (e.g., 300 feet, etc.), the use of the communications module as a repeater to transmit signals at a stronger power level allows the commander to communicate back and forth with all personnel and/or equipment at the incident site.
A signal received at response vehicle 204 that is targeted for response vehicle 206 or 208 may be retransmitted by response vehicle 204 at a higher power level (e.g., relative to the signal as received, etc.), so that the signal can reach the appropriate destination. In one embodiment, repeater module 416 may receive the signal from a mobile device of commander 202 and determine if a retransmission of the signal is necessary for the signal to reach its destination. Repeater module 416 may include logic for determining the position of the various response vehicles on site at the incident (e.g., to determine if a signal reached a destination, to receive feedback from other response vehicles, etc.) and determine an appropriate transmission power.
Repeater module 416 may additionally receive transmissions from other response vehicles that are not powerful enough to reach the commander 202 device. Repeater module 416 may retransmit the signal so that the signal is strong enough to reach commander 202. In some embodiments, onboard communications module 320 is configured to facilitate communications with user devices via one or more portable repeaters 214.
Referring now to
Process 500 includes establishing a wireless connection between a user device and a communications module of a response vehicle (block 502). Block 502 may include a user device initializing the connection (e.g., the user device sending a signal picked up by the communications module, etc.) or the communications module initializing the connection (e.g., upon arriving at an incident, the communications module, or the user device, may automatically set up the connection as the user is leaving the response vehicle, etc.).
Process 500 further includes authorizing user device access to communications with the response vehicle (block 504). Block 504 may include the user providing his or her credentials (e.g., login, password, etc.) or the user device automatically transmitting its credentials to the response vehicle, and the communications module verifying the user device.
In one embodiment, telemetry data, diagnostics data, or other data may be transmitted to the user device. The transmission may be based on a scheduled or automatic transmission of the data or a user request of the data. Process 500 may include formatting the data for display on the user device (block 506). For example, the data may be displayed on a browser of the user device instead of being displayed via an application. Process 500 further includes transmitting the data for display on the browser of the user device (block 508). The data may include telemetry data, diagnostics data, or any other data relating to the operation of the response vehicle or to the incident.
Referring now to
Process 600 includes detecting devices, which may include a plurality of user devices, response vehicles, and/or a commander user device (block 602). For example, a number of response vehicles (and personnel) may arrive at an incident, and block 602 may include determining the presence of the various response vehicles and/or user devices. Process 600 further includes determining the location of the various user devices and/or response vehicles (block 604), and determining a range of communications for the user devices and/or response vehicles (block 606). Blocks 604 and 606 may be executed to determine which communications modules are capable of reliably communicating with one another. Since the location of the various personnel and vehicles on site may vary, and Wi-Fi transmissions may be limited, some user devices including a commander user device may not be in range of all response vehicles. Block 606 may include receiving telemetry data from a plurality of sensors (e.g., sensors 344, etc.) and devices, and using the telemetry data to analyze the communications capabilities at the incident site.
Process 600 further includes receiving a transmission from a communications module (block 608). The transmission may originate from a user device and/or response vehicle, and may be intended for a communications module not in range of the original communications module. For example, the transmission may be from a commander user device for a response vehicle outside of wireless range. As another example, the transmission may be from a communications module of a response vehicle, including telemetry data, diagnostics data, and/or other data. Process 600 further includes retransmitting the transmission at a higher power than received (block 610), allowing the transmission to reach its destination.
Referring now to
Diagnostics module 322 may be configured to receive any type of data. As shown in
A fault detection module 706 is configured to use data from data analysis module 702 and logged data from data logging module 704 to determine if a fault exists in the response vehicle 100. In one embodiment, faults may relate to general vehicle performance (e.g., low fluid levels, faulty brakes, etc.). In another embodiment, faults may relate more specifically to the performance of response vehicle equipment. The response vehicle 100 may include a plurality of sensors (e.g., sensors 344, etc.) used to detect faults. For example, the vehicle may include an accelerometer to measure acceleration, deceleration, an accident or rollover condition, or other condition of the response vehicle 100.
In one embodiment, the faults defined by fault detection module 706 are detailed. For example, instead of providing a “check engine” alert to a user, fault detection module 706 may indicate a particular faulty engine component, to allow a user to diagnose the fault on site and to potentially address the fault without needing a mechanic, additional diagnostic charts or equipment, or other assistance. The faults may be displayed as warnings or alerts on the display unit 340 of the response vehicle 100 and/or a user device (e.g., display module 326, etc.). The display may generally include visuals and texts illustrating the fault and may include potential repairs for the fault (e.g., a picture of the faulty equipment, step-by-step directions to fix the fault or otherwise address the fault, etc.). Such a system offers significant advantages relative to traditional warning lights displayed upon detection of a fault (e.g., the “check engine” light, etc.).
A reporting module 708 may be provided to generate a report relating to one or more faults of the response vehicle 100. For example, reporting module 708 may format the fault data for display on a webpage on a browser of a user device. Onboard communications module 320 may then transmit the fault data wirelessly (as described above) to the user devices. In one embodiment, reporting module 708 may be configured to report fault data to a commander user device.
In some embodiments, reporting module 708 is configured to generate reports relating to response vehicle health and performance. For example, the report may include the status of equipment of the response vehicle 100 (e.g., a fuel level, if any equipment needs replacing or attending to, etc.). The report may be formatted for display on a webpage of a browser of a commander user device.
Referring now to
Process 800 includes receiving response vehicle data (block 802) and determining the presence of a vehicle fault using the response vehicle data (block 804). For example, the response vehicle data may relate to general vehicle functionality or to the status of various vehicle-related equipment. The response vehicle data may be checked to determine if any vehicle system is not performing properly, and block 804 includes determining a fault when a particular vehicle system is not performing properly.
Process 800 includes identifying a specific fault within the response vehicle (block 806). For example, instead of just identifying a fault with a particular vehicle system, the particular part or component associated with the fault may be identified by the diagnostics module. A fault report is generated for display on a webpage on a user device and/or display unit of the response vehicle (block 808). For example, the report may generally include fault information, as well as more specific details on the location of the fault and how to address the fault, among other details. Process 800 includes transmitting the fault report to the user device and/or display unit (block 810), such as a commander user device of a commander in charge of managing the response vehicle and/or a remote service technician.
Referring now to
In one embodiment, the activities of location module 324 are integrated with the other modules of vehicle management system 300. Location module 324 may communicate (via a wired or wireless connection) with onboard communications module 320 and diagnostics module 322 to support the activities of the modules. For example, if diagnostics module 322 identifies a fault or alert, location module 324 may be configured to generate location information for the response vehicle 100 with the fault to facilitate providing coordinated data to a commander user device.
As shown in
As shown in
In one embodiment, location module 324 includes a response vehicle locator 906 configured to locate other response vehicles responding to an incident. Response vehicle locator 906 may detect the presence of a response vehicle or may receive a transmission from a remote server indicating the future presence of other response vehicles at an incident site. Upon arriving at the incident, the determination that other response vehicles are at the incident may be used by response vehicle locator 906 to determine wireless communication capabilities between the response vehicles and user devices at the incident, as described above.
Referring now to
Process 1000 includes receiving incident information and providing navigation information for traveling to the incident (block 1002). Process 1000 further includes identifying geographical data relevant to the response vehicle and incident (block 1004). Upon identifying the incident at block 1002, the location module 324 may determine information that may be helpful to personnel. For example, if the incident is a fire, block 1004 may include identifying the location of hydrants or other water points near the fire. Block 1004 may further include identifying any potential hazards, risks, or zones at the incident (e.g., identifying a particular safe zone, a zone with high risk, identifying conditions that may make responding to the incident difficult, etc.). In some embodiments, block 1004 includes identifying tactical waypoints that can be used by response vehicles and personnel to more advantageously respond to the incident.
Process 1000 further includes identifying other response vehicle locations (block 1006). The other response vehicle locations may be used by other systems of the vehicle management system (e.g., onboard communications modules, etc.) to facilitate wireless communications with the other response vehicles.
Referring now to
While display module 326 is described as providing an interface for display on a user interface of the response vehicle 100, display module 326 may further provide the interface for display as a webpage on a user device. For example, as described above, a user or commander may access a webpage on a browser of a user device that allows the user or commander to view response vehicle information. In one embodiment, a commander may view the health or status of response vehicles on his or her user device. While display module 326 is described with reference to the response vehicle in
The touchscreen display of the response vehicle 100 may include any number of supporting buttons and other tactile user inputs to support interaction between a user and the display. For example, a plurality of push buttons may be located next to or below the display to provide the user with further options. It should be understood that the configuration of the touchscreen display in the response vehicle 100 may vary without departing from the scope of the present disclosure.
The display of the response vehicle 100 may include or support various technologies. For example, the display may be a touchscreen display and may be separated into any number of portions (e.g., a split-screen type display, etc.). For example, a first portion of the screen may be reserved for one particular type of display (e.g., warnings and alerts, etc.), while another portion of the screen may be reserved for general vehicle information (e.g., speed, fuel level, etc.). The display may be configured to handle any type of transition, animation, or other display feature that allows for ease of access of information on the display.
In one embodiment, the display is coupled to a USB input, allowing the display software to be updated. For example, such updates may include updating the maps stored on the display (e.g., to improve navigation features, etc.). Further, custom files may be downloaded to the display (e.g., custom logos, images, text, etc.) to personalize the display for use in the response vehicle 100.
The display may include any number of video inputs (e.g., from one or more cameras located on the response vehicle 100, etc.). For example, the display may be capable of receiving four video inputs and may display up to four video inputs simultaneously on the display. The display may be configured to detect when a camera feed is up, therefore determining when to display a video input on the display or not (e.g., not displaying a blank or blue screen, etc.).
As shown in
As shown in
In one embodiment, a command to display the video input may be received from, for example, diagnostics module 322 or another module. Display module 326 includes a fault information module 1106 configured to manage the display of fault information on the screen. For example, diagnostics module 322 may detect a scenario in which the response vehicle should not move (e.g., equipment attached to the vehicle is deployed, doors are open, etc.). Fault information module 1106 may be configured to generate a display with the “do not move truck” command displayed on the screen, along with a diagram or other text or image accompanying the command. As another example, a seat belt fault may be generated for display on the screen by fault information module 1106 if diagnostics module 322 detects that a seat belt is not being worn by an occupant. As another example, if diagnostics module 322 generates a tire pressure warning, fault information module 1106 may generate a display, which may include identifying the tire with low pressure along with the pressure level of all the tires of the response vehicle. In various embodiments, the activities of fault information module 1106 and diagnostics module 322 may be shared.
Referring now to
Referring to
When the response vehicle arrives at an incident, the user interface 1108 of
Referring to
Referring to
Referring to
Referring now to
Referring now to
In one embodiment, display module 326 is configured to provide location information to a user. In
In
As described above, the user may select a touchable widget relating to the diagnostics menu. The user may then be presented with a menu 1108 as shown in
The user may select “system” to be presented with the user interface 1108 of
Referring again to
The construction and arrangement of the systems and methods as shown in the various exemplary embodiments are illustrative only. Although only a few embodiments have been described in detail in this disclosure, many modifications are possible (e.g., variations in sizes, dimensions, structures, shapes and proportions of the various elements, values of parameters, mounting arrangements, use of materials, orientations, etc.). By way of example, the position of elements may be reversed or otherwise varied and the nature or number of discrete elements or positions may be altered or varied. Accordingly, all such modifications are intended to be included within the scope of the present disclosure. The order or sequence of any process or method steps may be varied or re-sequenced according to alternative embodiments. Other substitutions, modifications, changes, and omissions may be made in the design, operating conditions and arrangement of the exemplary embodiments without departing from the scope of the present disclosure.
The present disclosure contemplates methods, systems and program products on memory or other machine-readable media for accomplishing various operations. The embodiments of the present disclosure may be implemented using existing computer processors, or by a special purpose computer processor for an appropriate system, incorporated for this or another purpose, or by a hardwired system. Embodiments within the scope of the present disclosure include program products or memory comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, by way of example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.
Although the figures may show a specific order of method steps, the order of the steps may differ from what is depicted. Also two or more steps may be performed concurrently or with partial concurrence. Such variation will depend on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the disclosure. Likewise, software implementations could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps.
This application is a continuation of U.S. patent application Ser. No. 16/208,002, filed Dec. 3, 2018, which is a continuation of U.S. patent application Ser. No. 15/097,278, filed Apr. 12, 2016, which claims the benefit of U.S. Provisional Patent Application No. 62/150,149, filed Apr. 20, 2015, all of which are incorporated herein by reference in their entireties.
| Number | Name | Date | Kind |
|---|---|---|---|
| 3790223 | Fontaine | Feb 1974 | A |
| 4152647 | Gladden | May 1979 | A |
| 4834207 | Havenhill | May 1989 | A |
| 4892014 | Morell | Jan 1990 | A |
| 5079435 | Tanaka | Jan 1992 | A |
| 5204670 | Stinton | Apr 1993 | A |
| 5450920 | Enk | Sep 1995 | A |
| 5505528 | Hamman | Apr 1996 | A |
| 5513244 | Joao et al. | Apr 1996 | A |
| 5533795 | Brooks | Jul 1996 | A |
| 5538274 | Schmitz et al. | Jul 1996 | A |
| 5820150 | Archer et al. | Oct 1998 | A |
| 5835868 | McElroy et al. | Nov 1998 | A |
| 5890080 | Coverdill et al. | Mar 1999 | A |
| 5897123 | Cherney et al. | Apr 1999 | A |
| 6105984 | Schmitz et al. | Aug 2000 | A |
| D460950 | Miller et al. | Jul 2002 | S |
| 6421593 | Kempen et al. | Jul 2002 | B1 |
| 6516914 | Andersen et al. | Feb 2003 | B1 |
| 6520494 | Andersen et al. | Feb 2003 | B1 |
| 6553290 | Pillar | Apr 2003 | B1 |
| 6561718 | Archer et al. | May 2003 | B1 |
| 6636790 | Lightner et al. | Oct 2003 | B1 |
| 6757597 | Yakes et al. | Jun 2004 | B2 |
| 6764085 | Anderson | Jul 2004 | B1 |
| 6779806 | Breitbach et al. | Aug 2004 | B1 |
| 6816059 | Yanaka | Nov 2004 | B2 |
| 6860332 | Archer et al. | Mar 2005 | B1 |
| 6882917 | Pillar et al. | Apr 2005 | B2 |
| 6883815 | Archer | Apr 2005 | B2 |
| 6885920 | Yakes et al. | Apr 2005 | B2 |
| 6909944 | Pillar et al. | Jun 2005 | B2 |
| 6922615 | Pillar et al. | Jul 2005 | B2 |
| 6976688 | Archer et al. | Dec 2005 | B2 |
| 6993421 | Pillar et al. | Jan 2006 | B2 |
| 7006902 | Archer et al. | Feb 2006 | B2 |
| 7024296 | Squires et al. | Apr 2006 | B2 |
| 7034678 | Burkley et al. | Apr 2006 | B2 |
| 7055880 | Archer | Jun 2006 | B2 |
| 7072745 | Pillar et al. | Jul 2006 | B2 |
| 7092803 | Kapolka et al. | Aug 2006 | B2 |
| 7107129 | Rowe et al. | Sep 2006 | B2 |
| 7113127 | Banet et al. | Sep 2006 | B1 |
| 7127331 | Pillar et al. | Oct 2006 | B2 |
| 7149197 | Garahi et al. | Dec 2006 | B2 |
| 7162332 | Pillar et al. | Jan 2007 | B2 |
| 7164977 | Yakes et al. | Jan 2007 | B2 |
| 7184862 | Pillar et al. | Feb 2007 | B2 |
| 7184866 | Squires et al. | Feb 2007 | B2 |
| 7207582 | Siebers et al. | Apr 2007 | B2 |
| 7234534 | Froland et al. | Jun 2007 | B2 |
| 7254468 | Pillar et al. | Aug 2007 | B2 |
| 7274976 | Rowe et al. | Sep 2007 | B2 |
| 7274979 | Fujioka | Sep 2007 | B2 |
| 7277782 | Yakes et al. | Oct 2007 | B2 |
| 7302320 | Nasr et al. | Nov 2007 | B2 |
| 7379797 | Nasr et al. | May 2008 | B2 |
| 7387348 | Archer et al. | Jun 2008 | B2 |
| 7389826 | Linsmeier et al. | Jun 2008 | B2 |
| 7392122 | Pillar et al. | Jun 2008 | B2 |
| 7412307 | Pillar et al. | Aug 2008 | B2 |
| 7439711 | Bolton | Oct 2008 | B2 |
| 7451028 | Pillar et al. | Nov 2008 | B2 |
| 7472914 | Anderson et al. | Jan 2009 | B2 |
| 7522979 | Pillar | Apr 2009 | B2 |
| 7555369 | Pillar et al. | Jun 2009 | B2 |
| 7689332 | Yakes et al. | Mar 2010 | B2 |
| 7705777 | Sanderford, Jr. | Apr 2010 | B2 |
| 7711460 | Yakes et al. | May 2010 | B2 |
| 7715962 | Rowe et al. | May 2010 | B2 |
| 7725225 | Pillar et al. | May 2010 | B2 |
| 7729831 | Pillar et al. | Jun 2010 | B2 |
| 7751778 | Ngan | Jul 2010 | B1 |
| 7756621 | Pillar et al. | Jul 2010 | B2 |
| 7761544 | Manasseh et al. | Jul 2010 | B2 |
| 7784554 | Grady et al. | Aug 2010 | B2 |
| 7792618 | Quigley et al. | Sep 2010 | B2 |
| 7835838 | Pillar et al. | Nov 2010 | B2 |
| 7848857 | Nasr et al. | Dec 2010 | B2 |
| 7874373 | Morrow et al. | Jan 2011 | B2 |
| 8000850 | Nasr et al. | Aug 2011 | B2 |
| 8050811 | Inbarajan et al. | Nov 2011 | B2 |
| 8086368 | Petricoin et al. | Dec 2011 | B2 |
| 8095247 | Pillar et al. | Jan 2012 | B2 |
| 8201656 | Archer et al. | Jun 2012 | B2 |
| 8212667 | Petite et al. | Jul 2012 | B2 |
| 8285439 | Hodges | Oct 2012 | B2 |
| 8333390 | Linsmeier et al. | Dec 2012 | B2 |
| 8376077 | Venton-Walters | Feb 2013 | B2 |
| 8402878 | Schreiner et al. | Mar 2013 | B2 |
| 8465025 | Venton-Walters et al. | Jun 2013 | B2 |
| 8520700 | Greene et al. | Aug 2013 | B2 |
| D689785 | Miller et al. | Sep 2013 | S |
| 8525660 | Miller et al. | Sep 2013 | B2 |
| 8526912 | Quade | Sep 2013 | B2 |
| 8596648 | Venton-Walters et al. | Dec 2013 | B2 |
| 8645014 | Kozlowski et al. | Feb 2014 | B1 |
| 8670879 | Angelucci | Mar 2014 | B1 |
| 8670897 | Ralson | Mar 2014 | B1 |
| 8764029 | Venton-Walters et al. | Jul 2014 | B2 |
| 8786423 | Miller et al. | Jul 2014 | B2 |
| 8798852 | Chen et al. | Aug 2014 | B1 |
| 8801017 | Ellifson et al. | Aug 2014 | B2 |
| 8805599 | Hibbert | Aug 2014 | B2 |
| 8821130 | Venton-Walters et al. | Sep 2014 | B2 |
| 8838325 | Tomik | Sep 2014 | B2 |
| 8839902 | Archer et al. | Sep 2014 | B1 |
| 8843263 | Willard | Sep 2014 | B2 |
| 8930229 | Bowne et al. | Jan 2015 | B2 |
| 8943946 | Richmond et al. | Feb 2015 | B1 |
| 8955859 | Richmond et al. | Feb 2015 | B1 |
| 8963705 | Miller et al. | Feb 2015 | B2 |
| 8967699 | Richmond et al. | Mar 2015 | B1 |
| 8991834 | Venton-Walters et al. | Mar 2015 | B2 |
| 8991840 | Zuleger et al. | Mar 2015 | B2 |
| 9016703 | Rowe et al. | Apr 2015 | B2 |
| 9045014 | Verhoff et al. | Jun 2015 | B1 |
| 9132805 | King | Sep 2015 | B1 |
| 9239000 | Barbour | Jan 2016 | B2 |
| 9291230 | Ellifson et al. | Mar 2016 | B2 |
| 9302129 | Betz et al. | Apr 2016 | B1 |
| 9366507 | Richmond et al. | Jun 2016 | B1 |
| 9421945 | Smathers | Aug 2016 | B1 |
| 10144389 | Archer et al. | Dec 2018 | B2 |
| 10237900 | Jackson et al. | Mar 2019 | B2 |
| 10525297 | Kay | Jan 2020 | B2 |
| 10685510 | Linsmeier | Jun 2020 | B2 |
| 10981538 | Archer | Apr 2021 | B2 |
| 20010009394 | Yanaka | Jul 2001 | A1 |
| 20030034875 | Yamagishi et al. | Feb 2003 | A1 |
| 20030035437 | Garahi et al. | Feb 2003 | A1 |
| 20030141130 | Fleming et al. | Jul 2003 | A1 |
| 20050113996 | Pillar et al. | May 2005 | A1 |
| 20050221759 | Spadafora | Oct 2005 | A1 |
| 20060271246 | Bell et al. | Nov 2006 | A1 |
| 20070294033 | Osentoski et al. | Dec 2007 | A1 |
| 20080082221 | Nagy | Apr 2008 | A1 |
| 20080103651 | Pillar et al. | May 2008 | A1 |
| 20080252487 | Mcclellan et al. | Oct 2008 | A1 |
| 20080284575 | Breed | Nov 2008 | A1 |
| 20080312786 | Day | Dec 2008 | A1 |
| 20090256690 | Golenski | Oct 2009 | A1 |
| 20110068895 | Gee et al. | Mar 2011 | A1 |
| 20110106374 | Margol et al. | May 2011 | A1 |
| 20120016558 | Ueno et al. | Jan 2012 | A1 |
| 20120303182 | Choi | Nov 2012 | A1 |
| 20120303212 | Miller et al. | Nov 2012 | A1 |
| 20130038444 | Miller et al. | Feb 2013 | A1 |
| 20130151065 | Ricci | Jun 2013 | A1 |
| 20130154820 | Miller et al. | Jun 2013 | A1 |
| 20130211623 | Thompson et al. | Aug 2013 | A1 |
| 20130254097 | Marathe et al. | Sep 2013 | A1 |
| 20130282238 | Ricci et al. | Oct 2013 | A1 |
| 20140011483 | Baumert et al. | Jan 2014 | A1 |
| 20140066132 | Burke et al. | Mar 2014 | A1 |
| 20140156111 | Ehrman | Jun 2014 | A1 |
| 20140195108 | Schumacher | Jul 2014 | A1 |
| 20140214261 | Ramamoorthy et al. | Jul 2014 | A1 |
| 20140277828 | Bullister et al. | Sep 2014 | A1 |
| 20140277844 | Luke | Sep 2014 | A1 |
| 20140303836 | Phelan | Oct 2014 | A1 |
| Number | Date | Country |
|---|---|---|
| 2805995 | Nov 2013 | CA |
| 202183043 | Apr 2012 | CN |
| 3006648 | Dec 2014 | FR |
| 57198119 | Dec 1982 | JP |
| 2003-256818 | Sep 2003 | JP |
| 2005-297796 | Oct 2005 | JP |
| WO-2005006260 | Jan 2005 | WO |
| WO-2014186041 | Nov 2014 | WO |
| Entry |
|---|
| Foreign Office Action Received for Chinese Application No. 201680030641.9, Oshkosh Corporation, 7 pages, dated Feb. 25, 2019. |
| International Search Report and Written Opinion for PCT application No. PCT/US2016/027169, dated Jul. 1, 2016, 14 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20210229628 A1 | Jul 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62150149 | Apr 2015 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16208002 | Dec 2018 | US |
| Child | 17229253 | US | |
| Parent | 15097278 | Apr 2016 | US |
| Child | 16208002 | US |
