DE102020215842A1 - Cloud-konnektivität für fahrzeuginterne sensormodule - Google Patents

Cloud-konnektivität für fahrzeuginterne sensormodule Download PDF

Info

Publication number
DE102020215842A1
DE102020215842A1 DE102020215842.8A DE102020215842A DE102020215842A1 DE 102020215842 A1 DE102020215842 A1 DE 102020215842A1 DE 102020215842 A DE102020215842 A DE 102020215842A DE 102020215842 A1 DE102020215842 A1 DE 102020215842A1
Authority
DE
Germany
Prior art keywords
vehicle
monitoring
metadata
monitoring device
monitoring devices
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020215842.8A
Other languages
English (en)
Inventor
Russ Watts
Krisztian Bakos
Stefan Weissert
Philip Ventimiglia
Karl Holodnick
George Lewis
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of DE102020215842A1 publication Critical patent/DE102020215842A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01N—INVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N33/00—Investigating or analysing materials by specific methods not covered by groups G01N1/00 - G01N31/00
    • G01N33/0004—Gaseous mixtures, e.g. polluted air
    • G01N33/0009—General constructional details of gas analysers, e.g. portable test equipment
    • G01N33/0027—General constructional details of gas analysers, e.g. portable test equipment concerning the detector
    • G01N33/0036—General constructional details of gas analysers, e.g. portable test equipment concerning the detector specially adapted to detect a particular component
    • G01N33/0047—Organic compounds
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • B60R16/0232—Circuits relating to the driving or the functioning of the vehicle for measuring vehicle parameters and indicating critical, abnormal or dangerous conditions
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3407—Route searching; Route guidance specially adapted for specific applications
    • G01C21/3438—Rendez-vous, i.e. searching a destination where several users can meet, and the routes to this destination for these users; Ride sharing, i.e. searching a route such that at least two users can share a vehicle for at least part of the route
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3453—Special cost functions, i.e. other than distance or default speed limit of road segments
    • G01C21/3484—Personalized, e.g. from learned user behaviour or user-defined profiles
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01N—INVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N33/00—Investigating or analysing materials by specific methods not covered by groups G01N1/00 - G01N31/00
    • G01N33/0004—Gaseous mixtures, e.g. polluted air
    • G01N33/0009—General constructional details of gas analysers, e.g. portable test equipment
    • G01N33/0027—General constructional details of gas analysers, e.g. portable test equipment concerning the detector
    • G01N33/0031—General constructional details of gas analysers, e.g. portable test equipment concerning the detector comprising two or more sensors, e.g. a sensor array
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01P—MEASURING LINEAR OR ANGULAR SPEED, ACCELERATION, DECELERATION, OR SHOCK; INDICATING PRESENCE, ABSENCE, OR DIRECTION, OF MOVEMENT
    • G01P15/00—Measuring acceleration; Measuring deceleration; Measuring shock, i.e. sudden change of acceleration
    • G01P15/14—Measuring acceleration; Measuring deceleration; Measuring shock, i.e. sudden change of acceleration by making use of gyroscopes
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S19/00—Satellite radio beacon positioning systems; Determining position, velocity or attitude using signals transmitted by such systems
    • G01S19/01—Satellite radio beacon positioning systems transmitting time-stamped messages, e.g. GPS [Global Positioning System], GLONASS [Global Orbiting Navigation Satellite System] or GALILEO
    • G01S19/13—Receivers
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01V—GEOPHYSICS; GRAVITATIONAL MEASUREMENTS; DETECTING MASSES OR OBJECTS; TAGS
    • G01V8/00—Prospecting or detecting by optical means
    • G01V8/10—Detecting, e.g. by using light barriers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00—Scenes; Scene-specific elements
    • G06V20/50—Context or environment of the image
    • G06V20/59—Context or environment of the image inside of a vehicle, e.g. relating to seat occupancy, driver state or inner lighting conditions
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/02—Registering or indicating driving, working, idle, or waiting time only
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R11/00—Arrangements for holding or mounting articles, not otherwise provided for
    • B60R11/04—Mounting of cameras operative during drive; Arrangement of controls thereof relative to the vehicle
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R11/00—Arrangements for holding or mounting articles, not otherwise provided for
    • B60R2011/0001—Arrangements for holding or mounting articles, not otherwise provided for characterised by position
    • B60R2011/0003—Arrangements for holding or mounting articles, not otherwise provided for characterised by position inside the vehicle
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R11/00—Arrangements for holding or mounting articles, not otherwise provided for
    • B60R2011/0001—Arrangements for holding or mounting articles, not otherwise provided for characterised by position
    • B60R2011/0003—Arrangements for holding or mounting articles, not otherwise provided for characterised by position inside the vehicle
    • B60R2011/0026—Windows, e.g. windscreen
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • B60W60/001—Planning or execution of driving tasks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1895—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for short real-time information, e.g. alarms, notifications, alerts, updates
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02A—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
    • Y02A50/00—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE in human health protection, e.g. against extreme weather
    • Y02A50/20—Air quality improvement or preservation, e.g. vehicle emission control or emission reduction by using catalytic converters

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Chemical & Material Sciences (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Automation & Control Theory (AREA)
  • Signal Processing (AREA)
  • Analytical Chemistry (AREA)
  • Medicinal Chemistry (AREA)
  • Food Science & Technology (AREA)
  • Biochemistry (AREA)
  • Immunology (AREA)
  • Pathology (AREA)
  • Combustion & Propulsion (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • Geophysics (AREA)
  • General Life Sciences & Earth Sciences (AREA)
  • Social Psychology (AREA)
  • Mechanical Engineering (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Traffic Control Systems (AREA)
  • Fittings On The Vehicle Exterior For Carrying Loads, And Devices For Holding Or Mounting Articles (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)

Abstract

Es wird ein Cloudspeicher-Backend zum Verwalten von Daten von fahrzeuginternen Sensormodulen offenbart, das vorteilhaft zur Verwendung im Zusammenhang eines Dienstes zur gemeinsamen Fahrzeugnutzung, wie beispielsweise eines Autovermietungsdienstes, eines autonomen Taxidienstes oder eines Mitfahrdienstes, ist. Die fahrzeuginternen Sensormodule sind dafür konfiguriert, einen Zustand des Fahrzeugs zu überwachen und passende Algorithmen, Modelle oder Schwellenwerte zu benutzen, um Sensordaten zu interpretieren und die Daten mit Metadaten und Ereigniserkennung anzureichern. Das Cloudspeicher-Backend empfängt relevante Sensordaten, Ereignisdaten oder andere Metadaten von den fahrzeuginternen Sensormodulen und speichert die Daten in einer Datenbank, die durch autorisierte Dritte zugänglich gemacht wird.

Description

  • QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
  • Diese Anmeldung beansprucht die Priorität der Vorläufigen US-Patentanmeldung Seriennr. 62/952,618, die den Titel „In-Vehicle Sensing Module for Monitoring a Vehicle (Fahrzeuginternes Sensormodul zum Überwachen eines Fahrzeugs)“ trägt und am 23. Dezember 2019 eingereicht wurde, beansprucht die Priorität der Vorläufigen US-Patentanmeldung Seriennr. 62/952,568, die den Titel „In-Vehicle Sensing Module for Monitoring a Vehicle (Fahrzeuginternes Sensormodul zum Überwachen eines Fahrzeugs)“ trägt und am 23. Dezember 2019 eingereicht wurde, und beansprucht die Priorität der Vorläufigen US-Patentanmeldung Seriennr. 62/952,623, die den Titel „In-Vehicle Sensing Module Having Cloud Connectivity (Fahrzeuginternes Sensormodul, das Cloud-Konnektivität aufweist)“ trägt und am 23. Dezember 2019 eingereicht wurde, deren Offenbarungen hierin durch Verweis in ihrer Gesamtheit aufgenommen werden.
  • Diese Anmeldung ist verwandt mit der Vorläufigen US-Patentanmeldung Seriennr. 17/116133 [Anwaltsaktenzeichen 1576-2491], eingereicht zum gleichen Datum hiermit, und mit der Vorläufigen US-Patentanmeldung Seriennr. 17/116165 [Anwaltsaktenzeichen 1576-2492], eingereicht zum gleichen Datum hiermit, deren Offenbarungen hierin durch Verweis in ihrer Gesamtheit aufgenommen werden.
  • GEBIET
  • Die Vorrichtung und das Verfahren, die in diesem Dokument offenbart werden, betreffen fahrzeuginterne Sensorik und insbesondere elektronische Hardware für ein fahrzeuginternes Sensormodul.
  • ALLGEMEINER STAND DER TECHNIK
  • Sofern hierin nicht anders angegeben, wird durch Einschließen in dieser Sektion nicht anerkannt, dass die in dieser Sektion beschriebenen Materialien der Stand der Technik sind.
  • Bei Diensten zur gemeinsamen Fahrzeugnutzung, wie beispielsweise Mitfahrdiensten, Taxidiensten und Autovermietungsdiensten, werden gemeinsam genutzte Fahrzeuge häufig durch Fahrer gefahren oder von Fahrgästen benutzt, die nicht der Eigentümer des Fahrzeugs sind. Ein verbreitetes Problem bei solchen Diensten kann sein, dass Kunden achtlos darüber sein können, wie sie das Fahrzeug während ihrer kurzen Zeit als Fahrgast oder Fahrer behandeln. Angesichts dessen führen Betreiber solcher Dienste häufig verschiedene Regeln oder Richtlinien bezüglich dessen ein, wie das Fahrzeug durch den Kunden zu behandeln sind. Jedoch sind modern Verkörperungen dieser Dienste technologiegetrieben und häufig völlig autonom, um so wenig oder keine unmittelbare Interaktion mit dem Eigentümer des Fahrzeugs oder dem Betreiber des Dienstes zu erfordern. Im Ergebnis kann eine wirksame Durchsetzung dieser Regeln oder Richtlinien herausfordernd und manchmal unerschwinglich teuer sein. Dementsprechend wäre es vorteilhaft, ein System bereitzustellen, das eine autonome Erkennung von Problemen innerhalb des Fahrzeugs ermöglicht, was die Notwendigkeit menschlichen Eingreifens beim Durchsetzen von Regeln oder Richtlinien sowie Beheben von Verletzungen minimiert.
  • KURZDARSTELLUNG
  • Es wird ein Verfahren zum Verwalten von Daten eines Fahrzeugüberwachungssystems offenbart. Das Fahrzeugüberwachungssystem weist mehrere Überwachungsvorrichtungen auf, wobei jede Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen in einem jeweiligen Fahrzeug eingebaut ist und wenigstens einen Sensor aufweist, der dafür konfiguriert ist, jeweilige Sensordaten zu erfassen. Das Verfahren umfasst ferner das Empfangen, an einem Server, von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, jeweiliger Metadaten, die angeben, ob wenigstens ein vorbestimmter Zustand des jeweiligen Fahrzeugs eingetreten ist, wobei die jeweiligen Metadaten durch die jeweilige Überwachungsvorrichtung auf Grundlage der jeweiligen Sensordaten festgestellt werden. Das Verfahren umfasst das Speichern, auf einem Speichergerät, das mit dem Server verbunden ist, für jede jeweilige Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, der jeweiligen Metadaten in Verbindung mit der jeweiligen Überwachungsvorrichtung. Das Verfahren umfasst ferner das Gewähren von Zugang zu den jeweiligen Metadaten, die von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen empfangen werden, durch wenigstens ein entferntes Datenverarbeitungsgerät.
  • Es wird ein System zum Verwalten von Daten eines Fahrzeugüberwachungssystems offenbart. Das System umfasst ein Sende/-Empfangsgerät, das dafür konfiguriert ist, mit mehreren Überwachungsvorrichtungen des Fahrzeugüberwachungssystems zu kommunizieren, wobei jede Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen in einem jeweiligen Fahrzeug eingebaut ist und wenigstens einen Sensor aufweist, der dafür konfiguriert ist, jeweilige Sensordaten zu erfassen. Das System umfasst ferner ein Speichergerät, das dafür konfiguriert ist, Daten zu speichern, die von den mehreren Überwachungsvorrichtungen empfangen werden. Das System umfasst ferner einen Prozessor, der wirksam mit dem Sende/-Empfangsgerät und dem Speichergerät verbunden ist. Der Prozessor ist dafür konfiguriert, das Sende/- Empfangsgerät zu betätigen, um, von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, jeweilige Metadaten zu empfangen, die angeben, ob wenigstens ein vorbestimmter Zustand des jeweiligen Fahrzeugs eingetreten ist, wobei die jeweiligen Metadaten durch die jeweilige Überwachungsvorrichtung auf Grundlage der jeweiligen Sensordaten festgestellt werden. Der Prozessor ist ferner dafür konfiguriert, das Speichergerät zu betätigen, um, für jede jeweilige Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, die jeweiligen Metadaten in Verbindung mit der jeweiligen Überwachungsvorrichtung zu speichern. Der Prozessor ist ferner dafür konfiguriert, das Sende/-Empfangsgerät und das Speichergerät zu betätigen, um Zugang zu den jeweiligen Metadaten, die von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen empfangen werden, durch wenigstens ein entferntes Datenverarbeitungsgerät zu gewähren.
  • Es wird ein nicht-flüchtiges rechnerlesbares Medium zum Verwalten von Daten eines Fahrzeugüberwachungssystems offenbart. Das Fahrzeugüberwachungssystem weist mehrere Überwachungsvorrichtungen auf, wobei jede Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen in einem jeweiligen Fahrzeug eingebaut ist und wenigstens einen Sensor aufweist, der dafür konfiguriert ist, jeweilige Sensordaten zu erfassen. Das rechnerlesbare Medium speichert Programmanweisungen, die, wenn sie durch einen Prozessor ausgeführt werden, veranlassen, dass der Prozessor ein Sende/- Empfangsgerät betätigt, um, von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, jeweilige Metadaten zu empfangen, die angeben, ob wenigstens ein vorbestimmter Zustand des jeweiligen Fahrzeugs eingetreten ist, wobei die jeweiligen Metadaten durch die jeweilige Überwachungsvorrichtung auf Grundlage der jeweiligen Sensordaten festgestellt werden. Das rechnerlesbare Medium speichert ferner Programmanweisungen, die, wenn sie durch einen Prozessor ausgeführt werden, veranlassen, dass der Prozessor ein Speichergerät betätigt, um, für jede jeweilige Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, die jeweiligen Metadaten in Verbindung mit der jeweiligen Überwachungsvorrichtung zu speichern. Das rechnerlesbare Medium speichert ferner Programmanweisungen, die, wenn sie durch einen Prozessor ausgeführt werden, veranlassen, dass der Prozessor das Sende/-Empfangsgerät und das Speichergerät betätigt, um Zugang zu den jeweiligen Metadaten, die von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen empfangen werden, durch wenigstens ein entferntes Datenverarbeitungsgerät zu gewähren.
  • Figurenliste
  • Die vorstehenden Aspekte und andere Merkmale eines fahrzeuginternen Sensorsystems werden in der folgenden Beschreibung erläutert, betrachtet in Verbindung mit den beigefügten Zeichnungen.
    • 1 zeigt ein vereinfachtes Blockdiagramm eines Fahrzeugüberwachungssystems, das ein fahrzeuginternes Sensormodul zum Überwachen eines gemeinsam genutzten Fahrzeugs aufweist.
    • 2 zeigt beispielhafte elektronische Komponenten des fahrzeuginternen Sensormoduls von 1.
    • 3 zeigt ein Verfahren zum Betreiben des fahrzeuginternen Sensormoduls von 1, um wenigstens eine Kabine eines gemeinsam genutzten Fahrzeugs zu überwachen.
    • 4 zeigt ein Foto der Kabine des gemeinsam genutzten Fahrzeugs, in dem zurückgelassene Gegenstände mit Kästen markiert sind.
    • 5 zeigt ein Foto der Kabine des gemeinsam genutzten Fahrzeugs, in dem Schmutz auf dem Boden des Fahrzeugs mit Kästen markiert ist.
    • 6 zeigt ein Foto der Kabine des gemeinsam genutzten Fahrzeugs, in dem Verunreinigungen auf dem Boden und den Sitzen des Fahrzeugs mit Kästen markiert sind.
    • 7 zeigt beispielhafte Komponenten des Cloudspeicher-Backends von 1.
    • 8 zeigt ein Verfahren zum Betreiben des Cloudspeicher-Systems von 1, um Daten zu verwalten, die von mehreren fahrzeuginternen Sensormodulen hochgeladen werden.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Zu den Zwecken des Förderns eines Verständnisses der Prinzipien der Offenbarung wird nun Bezug auf die Ausführungsformen genommen, die in den Zeichnungen illustriert und in der folgenden schriftlichen Beschreibung beschrieben werden. Es versteht sich, dass dadurch keinerlei Beschränkung des Geltungsbereichs der Offenbarung beabsichtigt ist. Es versteht sich ferner, dass die vorliegende Offenbarung jegliche Änderungen und Modifikationen an den illustrierten Ausführungsformen einschließt und weitere Anwendungen der Prinzipien der Offenbarung einschließt, wie sie einer Fachperson auf dem Gebiet, das diese Offenbarung betrifft, normalerweise in den Sinn kommen würden.
  • Systemüberblick
  • 1 zeigt ein vereinfachtes Blockdiagramm eines Fahrzeugüberwachungssystems 100, das ein fahrzeuginternes Sensormodul 104 zum Überwachen wenigstens einer Kabine 108 eines gemeinsam genutzten Fahrzeugs 102 aufweist. Das Fahrzeugüberwachungssystem 100 ist vorteilhaft zur Verwendung im Zusammenhang eines Dienstes zur gemeinsamen Fahrzeugnutzung, bei dem das gemeinsam genutzte Fahrzeug 102 durch Fahrer gefahren oder von Fahrgästen benutzt wird, die nicht der Eigentümer des gemeinsam genutzten Fahrzeugs 102 sind. Solche Dienste zur gemeinsamen Fahrzeugnutzung könnten einen Autovermietungsdienst, einen autonomen Taxidienst oder einen Mitfahrdienst einschließen, sind aber nicht darauf beschränkt. Bei vielen solcher Dienste zur gemeinsamen Fahrzeugnutzung kann ein Kunde die Dienste des Dienstes zur gemeinsamen Fahrzeugnutzung auf eine automatisierte Weise unter Verwendung einer Smartphone-Anwendung, einer Website, eines Kiosks vor Ort oder dergleichen in Anspruch nehmen, was wenig oder kein menschliches Eingreifen durch den Betreiber des Dienstes zur gemeinsamen Fahrzeugnutzung erfordert.
  • Das fahrzeuginterne Sensorsystem 104 ermöglicht es Betreibern des Dienstes zur gemeinsamen Fahrzeugnutzung vorteilhafterweise, mit minimalem menschlichen Eingreifen den Zustand des gemeinsam genutzten Fahrzeugs 102 zu überwachen, Regeln und Richtlinien durchzusetzen und dem Kunden zusätzliche Leistungen bereitzustellen. Solche Regeln und Richtlinien könnten Regeln gegen Rauchen in dem gemeinsam genutzten Fahrzeug 102 oder Aufschläge für jegliches erforderliche Reinigen des gemeinsam genutzten Fahrzeugs 102 nach der Nutzung durch den Kunden einschließen. Außerdem kann der Betreiber zusätzliche Leistungen für den Kunden bereitstellen, wie beispielsweise ihn über zurückgelassene Gegenstände zu unterrichten.
  • Das fahrzeuginterne Sensorsystem 104 schließt ein fahrzeuginternes Sensormodul 112 ein, das wenigstens eine Steuerung, ein Mobilfunk-Sende- /Empfangsgerät/Modem und einen oder mehrere integrierte Sensoren 116, die dafür konfiguriert sind, einen Zustand wenigstens der Kabine 108 zu überwachen, aufweist, vorzugsweise integriert in einem gemeinsamen Gehäuse, das in die Kabine 108 des Fahrzeugs eingebaut ist. In einigen Ausführungsformen ist das Gehäuse dafür konfiguriert, auf einer Fläche innerhalb der Kabine 108 des gemeinsam genutzten Fahrzeugs 102, wie beispielsweise einem Armaturenbrett oder einer Windschutzscheibe, angebracht zu werden. Alternativ ist das Gehäuse in einer Ausführungsform angepasst zum Nachrüsten in ein(e) bestimmte(s) Marke und Modell des gemeinsam genutzten Fahrzeugs 102, wie beispielsweise anstelle eines Brillenhalters. In einigen Ausführungsformen schließt ein fahrzeuginternes Sensorsystem 104 ferner zusätzliche externe Sensoren 120 ein, die an oder überall in dem gemeinsam genutzten Fahrzeug 102 angeordnet sind, die über einen oder mehrere Kommunikationsbusse 124 wirksam mit dem fahrzeuginternen Sensormodul 112 verbunden sind. In einigen Ausführungsformen können die Sensoren 116, 120, die in dem fahrzeuginternen Sensormodule 112 verwendet werden, spezifisch für ein(e) bestimmte(s) Marke und Modell des gemeinsam genutzten Fahrzeugs 102 sein.
  • Zusätzlich zu dem fahrzeuginternen Sensorsystem 104 schließt das gemeinsam genutzte Fahrzeug 102 ein elektronisches Fahrzeug-Steuergerät (electronic control unit - „ECU“) 128, ein Antriebssystem 132 und ein Fahrzeugbatterie 136 ein. In einer Ausführungsform ist das Fahrzeug-ECU 128 dafür konfiguriert, das Antriebssystem 132 sowie verschiedene Elektronik des Fahrzeugs, wie beispielsweise Lichter, Schlösser, Lautsprecher, Anzeigen usw., zu betreiben. Das Fahrzeug-ECU 128 kann mit dieser verschiedenen Elektronik und dem Antriebssystem 132 sowie mit dem fahrzeuginternen Sensormodul 112 über den einen oder die mehreren Kommunikationsbusse 124 kommunizieren. In einer Ausführungsform übermittelt das Fahrzeug-ECU 128 bestimmte telemetrische Daten an das fahrzeuginterne Sensormodul 112, wie beispielsweise eine Fahrzeuggeschwindigkeit oder Fahrtrichtung, und folglich kann das Fahrzeug-ECU 128 als einer der externen Sensoren 120 betrachtet werden. Das Antriebssystem 132 des gemeinsam genutzten Fahrzeugs 102 schließt einen Antriebsmotor, zum Beispiel einen Verbrennungsmotor und/oder einen oder mehrere Elektromotoren, der die Räder des gemeinsam genutzten Fahrzeugs 102 antreibt, und die Lenk- und Bremskomponenten, die ermöglichen, dass das gemeinsam genutzte Fahrzeug 102 auf eine gesteuerte Weise bewegt wird, ein. Die Fahrzeugbatterie 136 ist dafür konfiguriert, über eine Stromleitung 140 (z. B. eine 12V-Stromleitung, wie beispielsweise die ständig aktive Stromleitung oder die geschaltete/Zubehör-Stromleitung des gemeinsam genutzten Fahrzeugs 102) Betriebsenergie für das fahrzeuginterne Sensormodul 112, die externen Sensoren 120, das Fahrzeug-ECU 128 und/oder jegliche andere Fahrzeugelektronik des gemeinsam genutzten Fahrzeugs 102 bereitzustellen.
  • Das fahrzeuginterne Sensormodul 112 ist dafür konfiguriert, einen Zustand wenigstens der Kabine 108 des Fahrzeugs zu überwachen. Insbesondere ist das fahrzeuginterne Sensormodul 112 dafür konfiguriert, von den Sensoren 116, 120 empfangene Sensordaten zu verarbeiten, um auf eine(n) oder mehrere Bedingungen, Qualitäten oder Zustände des gemeinsam genutzten Fahrzeugs 102 zu schließen. Zum Beispiel kann das fahrzeuginterne Sensormodul 112 erkennen, ob das gemeinsam genutzte Fahrzeug 102 sauber/schmutzig ist, dass das gemeinsam genutzte Fahrzeug 102 beschädigt oder an einem Zusammenstoß beteiligt worden ist, ob das gemeinsam genutzte Fahrzeug 102 Zigarettenrauch oder anderen unangenehmen Gerüchen ausgesetzt gewesen ist und/oder ob ein Gegenstand in das gemeinsam genutzten Fahrzeug 102 zurückgelassen worden ist. Das fahrzeuginterne Sensormodul 112 benutzt geeignete Algorithmen, Modelle (z. B. künstliche neuronale Netze) oder Schwellenwerte, um die Sensordaten zu interpretieren und die Daten mit Metadaten und Ereigniserkennung anzureichern. Es wird für die Durchschnittsfachleute zu erkennen sein, dass sich der Begriff „Metadaten“ auf beliebige Daten bezieht, die Informationen über andere Daten (z. B. die Sensordaten) beschreiben oder geben.
  • Zu diesem Zweck können, in Abhängigkeit von den bestimmten Bedingungen, Qualitäten oder Zuständen des gemeinsam genutzten Fahrzeugs 102, das zu überwachen ist, die Sensoren 106, 120 eine breite Vielfalt von Sensoren, einschließlich von Kameras, Mikrofonen, Kreiseln, Beschleunigungsmessern, Rauchdetektoren, Gassensoren oder anderen Luftgüte-/Partikelsensoren, Temperatursensoren und/oder Feuchtigkeitssensoren, einschließen. In einer Ausführungsform schließen die externen Sensoren 120 eine Fahrzeugkamera ein, die innerhalb der Kabine 108 angeordnet ist, um Bilder der Kabine 108 aufzunehmen, wie beispielsweise eine zu dem gemeinsam genutzten Fahrzeug gehörige oder eine als Nachrüstung eingebaute. In einer Ausführungsform schließen die externen Sensoren 120 ein Kreisel-/Beschleunigungsmesser-Modul ein, das zum Beispiel ein Mikrofon, einen Kreisel und einen Beschleunigungsmesser einschließt, die in einem einzigen Gehäuse integriert sind, das an dem Fahrgestell des gemeinsam genutzten Fahrzeugs 102 befestigt ist.
  • Das fahrzeuginterne Sensormodul 112 ist dafür konfiguriert, durch eine Mobilfink-Internetverbindung, relevante Sensordaten, Ereignisdaten oder andere Metadaten zum Speichern an demselben zu einem Cloudspeicher-Backend 150 hochzuladen. Auf die zu dem Cloudspeicher-Backend 150 hochgeladenen Daten kann durch ein Dritten-Cloud-Backend 160 zugegriffen werden. Das Dritten-Backend 160 ist zum Beispiel mit dem oben erörterten Dienst zur gemeinsamen Fahrzeugnutzung, wie beispielsweise einem Autovermietungsdienst, einem autonomen Taxidienst oder einem Mitfahrdienst, verknüpft. Auf diese Weise kann ein Betreiber des Dienstes zur gemeinsamen Fahrzeugnutzung mit minimalem menschlichen Eingreifen den Zustand des gemeinsam genutzten Fahrzeugs 102 überwachen, Regeln und Richtlinien durchsetzen und zusätzliche Leitungen für den Kunden bereitstellen.
  • Fahrzeuginternes Sensormodul
  • Unter Bezugnahme auf 2 werden beispielhafte elektronische Komponenten des fahrzeuginternen Sensormoduls 112 gezeigt. Das fahrzeuginterne Sensormodul 112 umfasst ein Gehäuse 204, innerhalb dessen wenigstens eine gedruckte Leiterplatte (printed circuit board - PCB) 208 enthalten und angebracht ist. Die PCB 208 unterstützt mehrere elektrische Komponenten und verbindet sie elektrisch miteinander, wobei sie wenigstens eine Steuerung 212 einschließt, die dafür konfiguriert ist, das fahrzeuginterne Sensormodul 112 zu betreiben.
  • Die Steuerung 212 schließt wenigstens einen Prozessor und zugeordneten Speicher ein. Es wird für die Durchschnittsfachleute zu erkennen sein, dass ein „Prozessor“ ein beliebiges Hardwaresystem, einen Hardwaremechanismus oder eine Hardwarekomponente einschließt, das/der/die Daten, Signale oder andere Informationen verarbeitet. Dementsprechend kann der Prozessor ein System mit einer zentralen Verarbeitungseinheit, Grafikverarbeitungseinheiten, mehreren Verarbeitungseinheiten, dedizierten Schaltungen zum Erreichen von Funktionalität, programmierbarer Logik oder anderen Verarbeitungssystemen einschließen. Der Speicher kann eine beliebige Art von Gerät sein, das zum Speichern von Informationen in der Lage ist, auf die durch den Prozessor zugegriffen werden kann, wie beispielsweise eine Flash-Speicherkarte, ROM, RAM, Festplattenlaufwerke, Disks oder ein beliebiges von verschiedenen anderen rechnerlesbaren Medien, die als flüchtige oder nicht-flüchtige Datenspeichergeräte dienen, wie es für die Durchschnittsfachleute zu erkennen sein wird. Der Speicher ist dafür konfiguriert, Programmanweisungen zu speichern, die, wenn sie durch den Prozessor ausgeführt werden, ermöglichen, dass das fahrzeuginterne Sensormodul 112 verschiedene Operation durchführt, einschließlich des Überwachens der Kabine 108 des gemeinsam genutzten Fahrzeugs 102, wie oben beschrieben.
  • In der illustrierten Ausführungsform nimmt die Steuerung 212 die Form einer Internet-der-Dinge- (Internet of Things - IoT-) Steuerung 212 an, die integrierte Merkmale und Funktionalitäten jenseits derjenigen einer allgemeinen Mehrzwecksteuerung aufweist. Zu diesem Zweck ist die IoT-) Steuerung 212, in der illustrierten Ausführungsform, als ein Einchipsystem (system on a chip - SoC) konfiguriert, das auf der PCB 208 angeordnet ist. Alternativ kann die IoT-Steuerung 212 äquivalent als ein Einmodulsystem (system on a module - SoM) konfiguriert sein, bei dem die Teilkomponenten derselben auf wenigstens einer diskreten PCB angeordnet sind, die mit der PCB 208 durch ein Kabel und/oder einen Modulverbinder verbunden ist. In beiden Fällen schließt die IoT-Steuerung 212 integrierte Merkmale und Funktionalitäten jenseits des Prozessors und des Speichers ein.
  • In einigen Ausführungsformen stellt die IoT-Steuerung 212 vorteilhafterweise integrierte Mobiltelefonie-Funktionalität bereit. Zu diesem Zweck umfasst die IoT-Steuerung 212 ein Mobiltelefonie-Modem und/oder -Sende-/Empfangsgerät sowie beliebige andere Prozessoren, Speicher, Oszillatoren oder andere Hardware, die herkömmlicherweise in einem Mobiltelefonie-Modul eingeschlossen sind, Das Mobiltelefonie-Modem ist dafür konfiguriert, über Drahtlostelefonie-Netze, wie beispielsweise Global-System-for-Mobiles- (GSM-), Code-Division-Multiple-Access-(CDMA-) und/oder Long-Term-Evolution- (LTE-) Netze, mit dem Internet zu kommunizieren. Es sollte zu erkennen sein, dass in alternativen Ausführungsformen ein diskretes Mobiltelefonie-Modul auf der PCB 208 bereitgestellt werden kann, das von der Steuerung 212 gesondert ist.
  • Das Mobiltelefonie-Modem der IoT-Steuerung 212 ist über einen Antennenverbinder 216, der auf der PCB 208 angeordnet ist, mit einer Mobilfunkantenne 214 verbunden. In wenigstens einer Ausführungsform ist die Mobilfunkantenne 214 innerhalb des Gehäuses 204, aber gesondert von der PCB 208, angeordnet und kann zum Beispiel eine flexible Antenne einschließen, die entlang innerer Seitenwände des Gehäuses 24 oder auf eine andere Weise, die dafür ausgelegt ist, den Mobilfunkempfang des fahrzeuginternen Sensormoduls 112 zu verbessern, angebracht ist. Das Mobiltelefonie-Modem ist ferner mit einer Subscriber-Identity-Module- („SIM“-) Karte 220 verbunden, die in einen SIM-Kartenhalter 222 eingesetzt ist, der auf der PCB 208 angeordnet und dafür konfiguriert ist, die SIM-Karte 220 mit der IoT-Steuerung 212 zu verbinden. Die SIM-Karte 220 stellt Identifizierungsinformationen bereit, um zu ermöglichen, dass das Mobiltelefonie-Modem auf das Drahtlostelefonie-Netz zugreift, wie es auf dem Gebiet allgemein bekannt ist.
  • In einigen Ausführungsformen stellt die IoT-Steuerung 212 vorteilhafterweise integrierte Global-Navigation-Satellite-System- (GNSS-) Funktionalität bereit. Zu diesem Zweck umfasst die IoT-Steuerung 212 einen GNNS-Empfänger sowie beliebige andere Prozessoren, Speicher, Oszillatoren oder andere Hardware, die herkömmlicherweise in einem GNNS-Modul eingeschlossen sind. Der GNSS-Empfänger ist dafür konfiguriert, Signale von GNSS-Satelliten zu empfangen, aus denen Positionsdaten bestimmt werden können. Der GNSS-Empfänger ist dafür konfiguriert, eines oder mehrere von zum Beispiel GPS, GLONASS, BeiDou und Galileo oder ein beliebiges anderes GNSS zu unterstützen. Der GNSS-Empfänger ist mit einer GNSS-Antenne 224 verbunden, um einen Empfang der GNSS-Signale zu ermöglichen. In der illustrierten Ausführungsform ist die GNSS-Antenne 224 in oder auf der PCB 208 angeordnet, kann aber alternative gesondert innerhalb oder außerhalb des Gehäuses 204 angeordnet sein. Es sollte zu erkennen sein, dass in alternativen Ausführungsformen ein diskretes GNSS-Modul auf der PCB 208 bereitgestellt werden kann, das von der Steuerung 212 gesondert ist.
  • In einigen Ausführungsformen (nicht gezeigt) kann die IoT-Steuerung 212 ferner integrierte Bluetooth®- und/oder Wi-Fi®-Sende-/Empfangsgeräte einschließen, die dafür konfiguriert sind, lokal mit einem Smartphone oder einem anderen intelligenten Gerät im Besitz des Fahrgasts oder Fahrers, der das gemeinsam genutzte 102 nutzt, zu kommunizieren. Gleichfalls können, in einigen Ausführungsformen, diskrete Bluetooth®- und/oder Wi-Fi®-Sende-/Empfangsgeräte auf der PCB 208 bereitgestellt werden, die von der Steuerung 212 gesondert sind.
  • Schließlich umfasst, in einigen Ausführungsformen, die IoT-Steuerung 212 vorteilhafterweise eine Vielzahl von integrierten Daten-/Peripherieschnittstellen zum wirksamen Verbinden mit einer Vielzahl von zusätzlichen Komponenten des fahrzeuginternen Sensorsystems 104, einschließlich von General-purpose input/output (GPIO), Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I2C oder I2C), Inter-IC Sound (I2S oder I2S), Secure Digital Input Output (SDIO), Universal Serial Bus (USB), USB High Speed Inter-Chip (HSIC) und Universal Asynchronous Receiver-Transmitter (UART). Auf diese Weise stellt die IoT-Steuerung 212 eine leichte Kompatibilität mit einer Vielzahl externer Sensoren 120 bereit, die innerhalb des gemeinsam genutzten Fahrzeugs 102 verfügbar sein könnten, ebenso wie sie Kompatibilität mit einer Vielzahl von Konfigurationen externer Sensoren 120 bereitstellt.
  • Wie oben bemerkt, schließt das fahrzeuginterne Sensormodul 112 einen oder mehrere integrierte Sensoren 116 ein, die dafür konfiguriert sind, einen Zustand des gemeinsam genutzten Fahrzeugs 102 oder wenigstens einer Kabine 108 desselben zu überwachen. Diese integrierten Sensoren 116 können unmittelbar mit der IoT-Steuerung 212 integriert, auf der PCB 208 angeordnet oder auf andere Weise gesondert von der PCB 208 innerhalb des Gehäuses 204 angeordnet sein. Die IoT-Steuerung 212 ist dafür konfiguriert, Sensordaten von den integrierten Sensoren 116 sowie einem beliebigen externen Sensor 120 zu empfangen und die Sensordaten in einen nicht-flüchtigen Speicher zu schreiben. Darüber hinaus ist die IoT-Steuerung 212 dafür konfiguriert, die Sensordaten zu verarbeiten, um eine Vielzahl von Metadaten zu bestimmen, die ebenfalls in den nicht-flüchtigen Speicher geschrieben werden. Zu diesem Zweck ist, in der illustrierten Ausführungsform, die IoT-Steuerung 212 mit einem Speichergerät 228 mit entfernbarem Speicher verbunden, das in einen entfernbaren Speichermedienhalter 230 eingesetzt ist, der auf der PCB 208 angeordnet und dafür konfiguriert ist, das Speichergerät 228 mit entfernbarem Speicher (z. B. über SIDO) mit der IoT-Steuerung 212 zu verbinden. Das Speichergerät 228 mit entfernbarem Speicher kann zum Beispiel eine Secure-Digital- (SD- ), SD-High-Capacity- (SDHC-) oder SD-Extended-Capacity- (SDXC-) Speicherkarte sowie eine beliebige gleichwertige Art von entfernbarer Speicherkarte oder anderer nichtflüchtiger Speichertechnologie umfassen.
  • In der illustrierten Ausführungsform schließen die integrierten Sensoren 116 eine Trägheitsmesseinheit (inertial measurement unit - IMU) 232 ein, die auf der PCB 208 angeordnet und (z. B. über I2C) mit der IoT-Steuerung 212 verbunden ist. Die IMU 232 schließt einen oder mehrere Kreiselsensoren und einen oder mehrere Beschleunigungsmesser ein. In einer Ausführungsform umfasst die IMU 232 einen integrierten 6-Achsen-Trägheitssensor, der sowohl dreiachsige Beschleunigungsmessungen als auch dreiachsige Kreiselmessungen bereitstellt. Wie weiter unten erörtert werden wird, schaltet, in wenigstens einigen Ausführungsformen, das fahrzeuginterne Sensormodul 112 in Reaktion auf Messungen von der IMU 232 von einem Niedrigleistungsmodus zu einem aktiven Zustand. Mit anderen Worten, die IMU 232 kann ein Wecksignal für die IoT-Steuerung 212 bereitstellen.
  • In der illustrierten Ausführungsform schließen die integrierten Sensoren 116 einen Umweltsensor 236 ein, der auf der PCB 208 angeordnet und mit der IoT-Steuerung 212 verbunden ist. Der Umweltsensor 236 ist dafür konfiguriert, Eigenschaften zu erfassen, die auf die Luftgüte in der Kabine schließen lassen, wie beispielsweise relative Feuchtigkeit, Luftdruck, Temperatur und Vorhandensein organischer Verbindungen, insbesondere flüchtiger organischer Verbindungen (volatile organic compounds - „VOC“). Dementsprechend schließt der Umweltsensor 236 eine Vielzahl einzelner Sensoren ein, die in einem einzigen Paket integriert sind. Es sollte jedoch zu erkennen sein, dass alternativ einzelne diskrete Sensoren bereitgestellt werden können, einschließlich eines VOC-Sensors, eines Feuchtigkeitssensors, eines Luftdrucksensors und eines Temperatursensors.
  • In der illustrierten Ausführungsform schließen die integrierten Sensoren 116 wenigstens ein Mikrofon 240 ein, das auf der PCB 208 angeordnet und (z. B. über I2S und/oder I2C) mit der IoT-Steuerung 212 verbunden ist. Das Mikrofon 240 umfasst eine beliebige Art von akustischem Sensor, der dafür konfiguriert ist, Geräusche innerhalb der Kabine 108 aufzuzeichnen. In wenigstens einer Ausführungsform schließen die integrierten Sensoren 116 wenigstens zwei Mikrofone 240 ein, die auf der PCB 208 entfernt voneinander angeordnet sind, um so Stereoton der Kabine 108 aufzuzeichnen. In einer Ausführungsform nimmt das/nehmen die Mikrofon(e) 240 die Form von Mikro-Elektro-Mechanischen System- (MEMS-) Mikrofonen an, die unmittelbar auf der PCB 208 angebracht sind. In wenigstens einer Ausführungsform ist das/sind die Mikrofon(e) 240 über einen Hardware-Audiocodec 242, der dafür konfiguriert ist, zum Beispiel eine Analog-Digital-Wandlung von Ton von dem/den Mikrofon(en) 240 durchzuführen, den Ton von dem/den Mikrofon(en) 240 zu verstärken, den Ton von dem/den Mikrofon(en) 240 zu filtern oder den Ton von dem/den Mikrofon(en) 240 auf andere Weise für eine geeignete Verwendung durch die IoT-Steuerung 212 zu codieren oder zu verarbeiten, mit der IoT-Steuerung 212 verbunden. In einer Ausführungsform definiert das Gehäuse 204 Öffnungen oder Gruppen von Öffnungen 244, die nahe dem/den Mikrofon(en) 240 auf der PCB 208 angeordnet sind und die einen Austausch von Luft zwischen dem Äußeren des Gehäuses 204 und dem Innenraum des Gehäuses 204 nahe dem/den Mikrofon(en) 240 ermöglichen. In einer Ausführungsform ist jedes von nahe dem/den Mikrofon(en) 240 von einer akustischen Dichtungsmanschette (nicht gezeigt) umgeben, deren eines Ende gegenüber der PCB 208 abdichtet. Die akustische Dichtungsmanschette, isolieren das/die Mikrofon(e) 240 akustisch, um so eine Überlagerung in dem durch die Öffnungen 244 übermittelten und durch das/die Mikrofon(e) 240 erfassten Schall zu verringern.
  • In der illustrierten Ausführungsform schließen die integrierten Sensoren 116 einen Partikelsensor 248 ein, der (z. B. über UART) mit der IoT-Steuerung 212 verbunden ist. Der Partikelsensor 248 ist dafür konfiguriert, die Partikelkonzentrationen in der Umgebungsluft der Kabine 108 zu erfassen. Der Partikelsensor 248 ist wenigstens dafür konfiguriert, Partikel zu erfassen, die Größe oder Massen aufweisen, die mit Rauch und insbesondere mit Tabakrauch und/oder Marihuanarauch verknüpft sind, kann aber ebenfalls Partikel erfassen, die mit anderen Schwebeteilchen oder Wasserdampf verknüpft sind. In wenigstens einer Ausführungsform ist der Partikelsensor 248 innerhalb des Gehäuses 204 gesondert von der PCB 208 angeordnet und ist mit Hilfe eines Kabels, das einen auf der PCB 2028 angeordneten Verbinder 250 mit einem Verbinder 252 des Partikelsensors 248 verbindet, mit der IoT-Steuerung 212 verbunden. In einer Ausführungsform definiert das Gehäuse 204 Öffnungen oder Gruppen von Öffnungen 254, die nahe dem Partikelsensor 248 angeordnet sind und die einen Austausch von Luft zwischen dem Äußeren des Gehäuses 204 und dem Innenraum des Gehäuses 204 nahe dem Partikelsensor 248 ermöglichen.
  • In der illustrierten Ausführungsform schließt das fahrzeuginterne Sensormodul 112 eine Anzeigeleuchte (z. B. eine LED) 258 ein, die an der PCB 208 oder dem Gehäuse 204 angebracht ist. Die Anzeigeleuchte 258 ist so angeordnet, dass sie durch eine transparente Linse oder Öffnung 260 des Gehäuses 204 sichtbar ist. Die IoT-Steuerung 212 ist dafür konfiguriert, die Anzeigeleuchte 258 zu betätigen, um Licht auszustrahlen, das einen Betriebszustand des fahrzeuginternen Sensormoduls 112 anzeigt.
  • In der illustrierten Ausführungsform schließt das fahrzeuginterne Sensormodul 112 ferner Energieversorgungen 264 ein, die dafür konfiguriert sind, Energie von der Fahrzeugbatterie 136 zu geeigneten Spannungen umzuwandeln, um der IoT-Steuerung 212 und anderen Komponenten des fahrzeuginternen Sensormoduls 112 Energie zuzuführen. In wenigstens einer Ausführungsform schließen die Energieversorgungen 264 eine Niedrigleistungszufuhr ein, um in einem Niedrigenergiemodus des fahrzeuginternen Sensormoduls 112 nur einer ausgewählten Teilmenge von Komponenten des fahrzeuginternen Sensormoduls 112 Energie zuzuführen. Die Energieversorgungen 264 sind mit einem externen I/O-Verbinder 266 verbunden, über den die Energieversorgungen 264 Eingangsleistung von der Fahrzeugbatterie 136 aufnehmen. Es sollte zu erkennen sein, dass die PCB 208, in einigen Ausführungsformen eine Batterie (nicht gezeigt) einschließt oder mit derselben verbunden ist, als eine sekundäre Energiequelle, falls die Energie von der Fahrzeugbatterie 136 unterbrochen ist.
  • In der illustrierten Ausführungsform schließt das fahrzeuginterne Sensormodul 112 ferner ein externes Kabel 268 ein, das mit dem externen I/O-Verbinder 266 verbunden ist und das Gehäuse 204 über eine in demselben definierte Öffnung 270 verlässt. In einer Ausführungsform schließt das externe Kabel 268 eine an der Öffnung 270 angeordnete Durchführungsdichtung 272 ein, die dafür konfiguriert ist, das externe Kabel 268 an der Öffnung 270 an dem Gehäuse 204 zu befestigen, um eine Zugentlastung bereitzustellen. Das externe Kabel 268 ist dafür konfiguriert, mit einer/einem oder mehreren Fahrzeugschnittstellen, -bussen oder -systemen des gemeinsam genutzten Fahrzeugs 102, die wenigstens die Stromleitung 140 einschließen, über einen oder mehrere Kabelbäume oder ein Äquivalent verbunden zu werden, um so eine Fahrzeugbatteriespannung 274 (z. B. 12 V) von der Fahrzeugbatterie 136 zu empfangen. Außerdem ist, in wenigstens einigen Ausführungsformen, das externe Kabel 268 dafür konfiguriert, mit dem einen oder den mehreren Kommunikationsbussen verbunden zu werden, um so Daten von den externen Sensoren 120 und/oder von dem Fahrzeug-ECU 128 zu empfangen.
  • In der illustrierten Ausführungsform schließen der eine oder die mehreren externen Sensoren 120 eine Fahrzeugkamera 276 ein, die innerhalb des gemeinsam genutzten Fahrzeugs 102 angeordnet und dafür konfiguriert ist, Bilder der Kabine 108 aufzunehmen. Die Fahrzeugkamera 276 kann eine bereits vorhandene Kamera sein, die zu der Marke und dem Modell des gemeinsam genutzten Fahrzeugs 102 gehört, oder kann eine Kamera sein, die als Nachrüstung in dem gemeinsam genutzten Fahrzeug 102 eingebaut worden ist. Das fahrzeuginterne Sensormodul 112 schließt auf der PCB 208 angeordnete Kameraauslöserschaltungen 278 ein, die mit dem externen I/O-Verbinder 266 und mit der IoT-Steuerung 212 (z. B. über GPIO) verbunden sind. Die IoT-Steuerung 212 ist dafür konfiguriert, die Kameraauslöserschaltungen 278 zu betätigen, um die Fahrzeugkamera 276 zu aktivieren, um in oder mehrere Bilder oder Video innerhalb der Kabine 108 aufzunehmen. Die IoT-Steuerung 212 ist dafür konfiguriert, die aufgenommenen Bilder von der Fahrzeugkamera 276 über die Kameraauslöserschaltungen 278 oder über eine andere Datenverbindung zu empfangen.
  • In der illustrierten Ausführungsform schließt das fahrzeuginterne Sensormodul 112 ferner Zündungssensorschaltungen 282 ein, die auf der PCB 208 angeordnet und mit dem externen I/O-Verbinder 266 und der IoT-Steuerung 212 verbunden sind. Die Zündungssensorschaltungen 282 sind dafür konfiguriert, die Spannung der Stromleitung 140 zu überwachen, die über den externen I/O-Verbinder 266 bereitgestellt wird, und festzustellen, wann eine Zündung des gemeinsam genutzten Fahrzeugs 102 aktiviert worden ist. Die Zündungssensorschaltungen 282 übermitteln dann ein Zündungssignal an die IoT-Steuerung 212, das anzeigt, dass das gemeinsam genutzte Fahrzeug 102 gestartet worden ist. Wie weiter unten erörtert werden wird, schaltet das fahrzeuginterne Sensormodul 112, in wenigstens einigen Ausführungsformen, in Reaktion auf das Zündungssignal von einem Niedrigleistungsmodus zu einem aktiven Modus. In anderen Worten, das Zündungssignal kann als ein Wecksignal für die IoT-Steuerung 212 wirken.
  • In der illustrierten Ausführungsform schließt das fahrzeuginterne Sensormodul 112 ferner Batterieüberwachungsschaltungen 286 ein, die auf der PCB 208 angeordnet und mit dem externen I/O-Verbinder 266 und mit der IoT-Steuerung 212 (z. B. über GPIO und/oder einen ADC-Eingang) verbunden sind. Die Batterieüberwachungsschaltungen 286 und/oder die IoT-Steuerung 212 sind dafür konfiguriert, eine Spannung und einen Strom der Stromleitung 140 zu überwachen, die über den externen I/O-Verbinder 266 bereitgestellt werden. In einigen Ausführungsformen wird ein Leistungszustand des fahrzeuginternen Sensormoduls 112 (z.B. ein, aus, Niedrigleistungsmodus, aktiver Modus) in Abhängigkeit von der Spannung und dem Strom der Stromleitung 140 gesteuert oder geändert.
  • Schließlich schließt, in der illustrierten Ausführungsform, das fahrzeuginterne Sensormodul 112 ferner einen externen Geräteverbinder 290 ein, der auf der PCB 208 angeordnet und mit dem externen I/O-Verbinder 266 und mit der IoT-Steuerung 212 (z. B. über USB) verbunden sind. Der externe Geräteverbinder 290 ermöglicht, dass ein externes Datenverarbeitungsgerät, wie beispielsweise ein Diagnosewerkzeug oder dergleichen, zeitweilig mit dem fahrzeuginternen Sensormodul 212 verbunden wird, um Daten von dem fahrzeuginternen Sensormodul 212 zu lesen oder zu empfangen. Der externe Geräteverbinder 290 kann zum Beispiel die Form eines USB-Verbinders (z. B. USB-A, USB-C, Mikro-USB usw.) oder dergleichen annehmen, dafür konfiguriert, eine drahtgebundene Kommunikation zwischen der IoT-Steuerung 212 und dem externen Datenverarbeitungsgerät zu ermöglichen.
  • Betrieb des fahrzeuginternen Sensormoduls
  • Es wird unten eine Vielzahl von Verfahren und Prozessen zum Betreiben des fahrzeuginternen Sensormoduls 112 beschrieben. In diesen Beschreibungen beziehen sich Aussagen, dass ein Verfahren, Prozessor und/oder System eine Aufgabe oder Funktion durchführt, auf eine Steuerung oder einen Prozessor (z. B. die IoT-Steuerung 212 des fahrzeuginternen Sensormoduls 112), die/der programmierte Anweisungen ausführt, die in nicht-flüchtigen rechnerlesbaren Speichermedien (z. B. dem Speicher der IoT-Steuerung 212 des fahrzeuginternen Sensormoduls 112 oder dem Speichergerät 228 mit entfernbarem Speicher) gespeichert sind, die wirksam mit der Steuerung oder dem Prozessor verbunden sind, um Daten zu handhaben oder um eine oder mehrere Komponenten in dem Fahrzeugüberwachungssystem 100 zu betätigen, um die Aufgabe oder Funktion durchzuführen. Außerdem können die Schritte der Verfahren in einer beliebigen umsetzbaren chronologischen Reihenfolge durchgeführt werden, ungeachtet der in den Figuren gezeigten Reihenfolge oder der Reihenfolge, in der die Schritte beschrieben werden.
  • 3 zeigt ein Verfahren 300 zum Betreiben des fahrzeuginternen Sensormoduls 112, um wenigstens die Kabine 108 eines gemeinsam genutzten Fahrzeugs 102 zu überwachen. Das Verfahren 300 erfasst und speichert vorteilhafterweise in einem nicht-flüchtigen Speicher Sensordaten während des Betriebs des gemeinsam genutzten Fahrzeugs 102, zum Beispiel im Zusammenhang eines Dienstes zur gemeinsamen Fahrzeugnutzung, wie beispielsweise eines Autovermietungsdienstes, eines autonomen Taxidienstes oder eines Mitfahrdienstes oder dergleichen. Darüber hinaus verarbeitet das Verfahren 300 vorteilhafterweise die Sensordaten, um Metadaten bereitzustellen, die ebenfalls in dem nicht-flüchtigen Speicher gespeichert werden. Das Verfahren 300 ermöglicht es vorteilhafterweise, dass Betreiber solcher Dienste zur gemeinsamen Fahrzeugnutzung mit minimalem menschlichen Eingreifen den Zustand des gemeinsam genutzten Fahrzeugs überwachen, Regeln und Richtlinien durchsetzen und dem Kunden zusätzliche Leistungen bereitstellen.
  • Das Verfahren 300 beginnt mit dem Einschalten des fahrzeuginternen Sensormoduls (Block 310). Im Einzelnen sind, wie oben bemerkt, die Batterieüberwachungsschaltungen 286 dafür konfiguriert, eine Spannung und einen Strom der Stromleitung 140 zu überwachen, die über den externen I/O-Verbinder 266 zugeführt werden. In einigen Ausführungsformen ist die Stromleitung 140, mit der über den externen I/O-Verbinder 266 verbunden wird, eine ständig aktive Stromleitung des gemeinsam genutzten Fahrzeugs 102, welche die Batteriespannung der Fahrzeugbatterie 136 unmittelbar zuführt. Es wird zu erkennen sein, dass, wenn sie genau gemessen wird, die Batteriespannung der Fahrzeugbatterie 136 verwendet werden kann, um einen Ladezustand der Fahrzeugbatterie 136 abzuschätzen. In einer Ausführungsform messen die Batterieüberwachungsschaltungen 286 die Batteriespannung, die über die Stromleitung 140 bereitgestellt wird, und stellt, als Reaktion darauf, dass die Batteriespannung eine vorbestimmte Schwellenspannung überschreitet, ein Einschaltsignal an die IoT-Steuerung 212 bereit, um das fahrzeuginterne Sensormodul 112 wenigstens teilweise einzuschalten. Die vorbestimmte Schwellenspannung ist eine Batteriespannung, die einem vorbestimmten Ladezustand der Fahrzeugbatterie entspricht, In einer Ausführungsform ist der vorbestimmte Ladezustand einer, bei dem die Fahrzeugbatterie 136 noch ausreichend Stromstärke bereitstellen kann, um das Fahrzeug zu starten. Auf diese Weise wird das fahrzeuginterne Sensormodul 112 nur mit Batterieleistung arbeiten, falls die Fahrzeugbatterie 136 ausreichend geladen ist, und wird nicht bewirken, dass die Fahrzeugbatterie unnötig entleert wird, falls das gemeinsam genutzte Fahrzeug 102 für einen ausgedehnten Zeitraum nicht gestartet wird.
  • In alternativen Ausführungsformen ist die Stromleitung 140, mit der über den externen I/O-Verbinder 266 verbunden wird, eine geschaltete/Zubehör-Stromleitung des gemeinsam genutzten Fahrzeugs 102, welche die Batteriespannung der Fahrzeugbatterie 136 nur bereitstellt, falls die Zündung aktiviert worden ist, um das gemeinsam genutzte Fahrzeug 102 zu starten (im Allgemeinen durch Umschalten eines Bedienungselements der Zündung, während die Bremsen gedrückt werden), oder falls Zubehörleistung des gemeinsam genutzten Fahrzeugs aktiviert worden ist (im Allgemeinen durch Umschalten eines Bedienungselements der Zündung, ohne dass die Bremsen gedrückt werden). Folglich stellen die Batterieüberwachungsschaltungen 286, als Reaktion auf das Erfassen der Batteriespannung von der Fahrzeugbatterie 136, ein Einschaltsignal an die IoT-Steuerung 212 bereit, um wenigstens teilweise einzuschalten.
  • Das Verfahren 300 setzt sich fort mit dem Betreiben des fahrzeuginternen Sensormoduls in einem Niedrigleistungsmodus, bis eine Weckbedingung eintritt (Block 320). Im Einzelnen beginnt, in Reaktion auf das Einschaltsignal, das fahrzeuginterne Sensormodul 112 den Betrieb in einem Niedrigleistungsmodus, in dem die IoT-Steuerung 212 eine Teilmenge von Komponenten des fahrzeuginternen Sensormoduls 112 aktiviert, um einzuschalten. In einem Ausführungsbeispiel werden, in dem Niedrigleistungsmodus, nur die IMU 232, der Umweltsensor 236, die Zündungssensorschaltungen 282 und die Niedrigleistungszufuhr der Energieversorgungen 264 aktiviert. Außerdem kann die IoT-Steuerung 212 selbst in einem Niedrigleistungszustand arbeiten, in dem bestimmte Funktionalitäten oder Teilkomponenten, wie beispielsweise die mit Mobilfunktelefonie und GNSS verbundenen, deaktiviert sind.
  • Das fahrzeuginterne Sensormodul 112 arbeitet in dem Niedrigleistungsmodus, bis eine Weckbedingung erfüllt ist, oder insbesondere, bis die IoT-Steuerung 212 ein Wecksignal empfängt. Als Reaktion auf das Empfangen des Wecksignals beginnt das fahrzeuginterne Sensormodul 112 den Betrieb in einem aktiven Modus, in dem die IoT Steuerung 212 alle Komponenten des fahrzeuginternen Sensormoduls 112 aktiviert, um einzuschalten. In einer Ausführungsform senden die Zündungssensorschaltungen 282 als Reaktion auf das Erkennen, dass die Zündung des gemeinsam genutzten Fahrzeugs 102 aktiviert worden ist, ein Wecksignal an die IoT-Steuerung 212. In einer Ausführungsform sendet die IMU 233 als Reaktion auf das Erkennen einer Störung des gemeinsam genutzten Fahrzeugs 102 (z. B. Beschleunigungs- oder Kreiselmessungen, die einen Schwellenwert überschreiten oder einem vorbestimmten Profil entsprechen), die zu Beispiel anzeigt, dass ein Fahrer das gemeinsam genutzte Fahrzeug 102 entriegelt hat und in die Kabine 108 eingestiegen ist, ein Wecksignal an die IoT-Steuerung 212. In einer Ausführungsform kann, falls die Mobilfunktelefonie-Funktionalität der IoT-Steuerung 212 während des Niedrigleistungsmodus funktionsfähig ist, das Wecksignal von dem Cloudspeicher-Backend 150 empfangen werden.
  • Das Verfahren 300 setzt sich fort mit dem Empfangen von Sensordaten von den integrierten Sensoren und den externen Sensoren und dem Schreiben der Sensordaten in einen lokalen nicht-flüchtigen Speicher (Block 330). Im Einzelnen beginnt, in dem aktiven Modus, die IoT-Steuerung 212, nach dem Empfangen des Wecksignals, Sensordaten von den integrierten Sensoren 116 und von den externen Sensoren 120 in das Speichergerät 228 mit entfernbarem Speicher oder in einen anderen nicht-flüchtigen Speicher zu schreiben, In einer Ausführungsform setzt die IoT-Steuerung 212 einen oder mehrere Ringpuffer (die ebenfalls als zirkuläre Puffer, zirkuläre Warteschlagen oder als zyklische Puffer bezeichnet werden können, auf dem Speichergerät 228 mit entfernbarem Speicher um, um die Speicherung von neu gemessenen Sensordaten und die Löschung von alten Sensordaten zu verwalten.
  • Das Verfahren 300 setzt sich fort mit dem Verarbeiten der Sensordaten, um Metadaten, einschließlich von Ereignisdaten zu bestimmen, und dem Schreiben der Metadaten in den lokalen nicht-flüchtigen Speicher (Block 340). Im Einzelnen ist die IoT-Steuerung 212 dafür konfiguriert, die von den integrierten Sensoren 116 oder von den externen Sensoren 120 empfangenen Sensordaten zu verarbeiten, um die daten mit Metadaten und insbesondere Ereigniserkennung anzureichern. Wie oben erörtert, können die Sensoren 116, 120 eine breite Vielfalt von Sensoren, einschließlich von Kameras, Mikrofonen, Kreiseln, Beschleunigungsmessern, Rauchdetektoren, Gassensoren oder anderen Luftgüte-/Partikelsensoren, Temperatursensoren und/oder Feuchtigkeitssensoren, einschließen. Die IoT-Steuerung 212 verarbeitet die Sensordaten, um eine(n) oder mehrere Bedingungen, Qualitäten oder Zustände des gemeinsam genutzten Fahrzeugs 102 zu bestimmen und/oder das Eintreten eines oder mehrerer Ereignisse, die mit der/dem einen oder den mehreren Bedingungen, Qualitäten oder Zuständen des gemeinsam genutzten Fahrzeugs 102 verknüpft sind, zu erkennen. Die IoT-Steuerung 212 speichert die bestimmten Bedingungen, Qualitäten oder Zustände und die erkannten Ereignisse, die mit denselben verbunden sind, als Metadaten der gespeicherten Sensordaten auf dem Speichergerät 228 mit entfernbarem Speicher.
  • In wenigstens einigen Ausführungsformen ist die IoT-Steuerung 212 dafür konfiguriert, eine(n) oder mehrere Bedingungen, Qualitäten oder Zustände des gemeinsam genutzten Fahrzeugs 102 zu bestimmen und/oder das Eintreten eines oder mehrerer Ereignisse, die mit der/dem einen oder den mehreren Bedingungen, Qualitäten oder Zuständen des gemeinsam genutzten Fahrzeugs 102 verknüpft sind, unter Verwendung eines Algorithmus oder eines Modells, wie beispielsweise eines Maschinenlernmodells (z. B. eines künstlichen neuronalen Netzes) zu erkennen. In einer Ausführungsform ist die IoT-Steuerung 212 dafür konfiguriert, Aktualisierungen für den Algorithmus oder das Modell von dem Cloudspeicher-Backend 150, über das Mobilfunktelefonie-Modem derselben, zu empfangen.
  • In einigen Ausführungsformen betätigt, als Reaktion auf das Erkennen einer/eines bestimmten Qualität, Bedingung, Zustandes oder Ereignisses die IoT-Steuerung die Kameraauslöserschaltungen 276, um zu veranlassen, dass die Fahrzeugkamera 276 ein Bild oder Video der Kabine 108 aufnimmt. Die IoT-Steuerung 212 speichert das aufgenommene Bild als Metadaten der Sensordaten, aus denen die/der/das bestimmte Qualität, Bedingung, Zustand oder Ereignis erkannt wurde, auf dem Speichergerät 228 mit entfernbarem Speicher.
  • In einigen Ausführungsformen ist die IoT-Steuerung 212 dafür konfiguriert, auf Grundlage der durch die IMU 232 oder durch einen ähnlichen externen Sensor 120 bereitgestellten Beschleunigungs- und Kreiselmessungen festzustellen, ob das gemeinsam genutzte Fahrzeug 102 an einem Zusammenstoß beteiligt gewesen ist oder auf andere Weise mechanisch beschädigt worden ist. In einer Ausführungsform ist die IoT-Steuerung 212 dafür konfiguriert, als Reaktion darauf, dass die Beschleunigungs- und/oder die Kreiselmessungen einen vorbestimmten Schwellenwert überschreiten oder mit einem vorbestimmten Beschleunigungsprofil übereinstimmen, ein Zusammenstoß- oder Schadensereignis zu erkennen. In einer Ausführungsform führt die IoT-Steuerung 212 ein Maschinenlernmodell (z. B. ein künstliches neuronales Netz) aus, um auf Grundlage der Beschleunigungs- und/oder der Kreiselmessungen ein Zusammenstoß- oder Schadensereignis zu erkennen. In einer Ausführungsform erkennt die IoT-Steuerung 212, wo der Schaden eintrat (z. B. vorn links), und klassifiziert eine Schwere oder Stufe des Schadens (z. B. schwer) auf Grundlage der Beschleunigungs- und/oder der Kreiselmessungen oder anderer Sensordaten. In einer Ausführungsform führt die IoT-Steuerung 212 ein Maschinenlernmodell (z. B. ein künstliches neuronales Netz) aus, um auf Grundlage der Beschleunigungs- und/oder der Kreiselmessungen den erkannten Zusammenstoß oder Schaden zu klassifizieren. In einer Ausführungsform betätigt die IoT-Steuerung 212, als Reaktion auf ein Zusammenstoß- oder Schadensereignis, die Kameraauslöserschaltungen 278, um zu veranlassen, dass die Fahrzeugkamera 276 ein Bild oder Video der Kabine 108 aufnimmt.
  • In einigen Ausführungsformen ist die IoT-Steuerung 212 dafür konfiguriert, auf Grundlage der durch den Umweltsensor 236 bereitgestellten VOC-Messungen festzustellen, ob die Kabine 108 des gemeinsam genutzten Fahrzeugs 102 einen unangenehmen oder unnormalen Geruch aufweist. In einer Ausführungsform ist die IoT-Steuerung 212 dafür konfiguriert, als Reaktion darauf, dass die VOC-Messungen einen vorbestimmten Schwellenwert überschreiten oder mit einem vorbestimmten Profil übereinstimmen, ein unangenehmes/unnormales Geruchsereignis zu erkennen. In einer Ausführungsform führt die IoT-Steuerung 212 ein Maschinenlernmodell (z. B. ein künstliches neuronales Netz) aus, um auf Grundlage der VOC-Messungen ein unangenehmes/unnormales Geruchsereignis zu erkennen. In einer Ausführungsform betätigt die IoT-Steuerung 212, als Reaktion auf ein unangenehmes/unnormales Geruchsereignis, die Kameraauslöserschaltungen 278, um zu veranlassen, dass die Fahrzeugkamera 276 ein Bild oder Video der Kabine 108 aufnimmt.
  • Außerdem kann die IoT-Steuerung 212 in einigen Ausführungsformen dafür konfiguriert sein, auf Grundlage wenigstens der durch den Umweltsensor 236 bereitgestellten VOC-Messungen die in der Kabine 108 des gemeinsam genutzten Fahrzeugs 102 vorhandenen Düfte oder Gerüche zu identifizieren und/oder zu kategorisieren. Zum Beispiel identifiziert die IoT-Steuerung 212, auf Grundlage des chemischen Profils der in der Kabine 108 abgefühlten VOC und, in einigen Ausführungsformen, in Verbindung mit der abgefühlten Temperatur, Feuchtigkeit, Luftdruck und Partikelkonzentrationen, den Duft als zu einer bestimmten Kategorie von Gerüchen gehörend. Zum Beispiel ist die IoT-Steuerung 212, in einigen Ausführungsformen, dafür konfiguriert, Gerüche zu identifizieren und zu kategorisieren, die einem oder mehreren von Folgenden entsprechen: Marihuana, Tabak, Parfüm, Nahrungsmittel, Getränke, Alkohol, Urin, Erbrochenes, Fäkalien, tierische Gerüche, Schimmel, Benzin und andere Gerüche, die für Benutzer des Fahrzeugs 102 wahrnehmbar sein können. In einer Ausführungsform ist die IoT-Steuerung 212 dafür konfiguriert, ein Maschinenlernmodell (z. B. ein künstliches neuronales Netz) auszuführen, um auf Grundlage der erkannten VOC und, in einigen Ausführungsformen, ferner auf Grundlage der Temperatur-, Feuchtigkeits-, Luftdruck- und Partikelmessungen, die Gerüche in der Fahrzeugkabine 108 zu identifizieren und zu kategorisieren. In einigen Ausführungsformen betätigt die IoT-Steuerung 212, als Reaktion auf das Erkennen bestimmter Kategorien von Gerüchen, die Kameraauslöserschaltungen 278, um zu veranlassen, dass die Fahrzeugkamera 276 ein Bild oder Video der Kabine 108 aufnimmt.
  • In einigen Ausführungsformen ist die IoT-Steuerung 212 dafür konfiguriert, auf Grundlage der durch den Partikelsensor 248 bereitgestellten Schwebstoffmessungen festzustellen, ob ein Fahrer oder Fahrgast innerhalb der Kabine 108 des gemeinsam genutzten Fahrzeugs 102 raucht. In einer Ausführungsform ist die IoT-Steuerung 212 dafür konfiguriert, eine Kurve der Schwebstoffkonzentrationen über die Zeit zu überwachen und als Reaktion darauf, dass die Kurve der Schwebstoffkonzentrationen dem/der Referenzprofil/-kurve entspricht oder die Schwellenkonzentration überschreitet, ein Rauchereignis zu erkennen. In einer Ausführungsform führt die IoT-Steuerung 212 ein Maschinenlernmodell (z. B. ein künstliches neuronales Netz) aus, um auf Grundlage der Schwebstoffmessungen ein Rauchereignis zu erkennen. In einer Ausführungsform betätigt die IoT-Steuerung 212, als Reaktion auf ein Rauchereignis, die Kameraauslöserschaltungen 278, um zu veranlassen, dass die Fahrzeugkamera 276 ein Bild oder Video der Kabine 108 aufnimmt.
  • In einigen Ausführungsformen ist die IoT-Steuerung 212 dafür konfiguriert, auf Grundlage eines Bildes oder Videos der Kabine 108 festzustellen, ob Gegenstände, wie beispielsweise Telefone, Schlüssel oder Brillen, durch Fahrgäste des Fahrzeugs zurückgelassen worden sind. Im Einzelnen betätigt die IoT-Steuerung 212 die Kameraauslöserschaltungen 278, um zu veranlassen, dass die Fahrzeugkamera 276 ein Bild oder Video der Kabine 108 aufnimmt, nachdem ein Fahrer oder Fahrgast das gemeinsam genutzte Fahrzeug 102 verlässt. Die IoT-Steuerung 212 führt einen Bildanalysealgorithmus, wie beispielsweise ein Maschinenlernmodell (z. B. ein künstliches neuronales Netz) aus, um das aufgenommene Bild oder Video der Kabine 108 zu analysieren und verlorene oder zurückgelassene Gegenstände in dem gemeinsam genutzten Fahrzeug 102 zu erkennen. Falls ein verlorener oder zurückgelassener Gegenstand erkannt wird, dann speichert die IoT-Steuerung 212 ein Ereignis eines verlorenen oder zurückgelassenen Gegenstandes in den Metadaten. In einer Ausführungsform modifiziert die IoT-Steuerung 212 das aufgenommene Bild oder Video, um die verlorenen oder zurückgelassenen Gegenstände in dem aufgenommenen Bild oder Video zu markieren, wie beispielsweise mit Kästen 342, wie in 4 gezeigt, und listet die Gegenstände ebenfalls in Metadaten des Bildes oder Videos auf. In einer Ausführungsform unterscheidet und klassifiziert die IoT-Steuerung 212 die verlorenen oder zurückgelassenen Gegenstände, zum Beispiel unter Verwendung eines Maschinenlernmodells (z. B. eines künstlichen neuronalen Netzes), und schließt diese Klassifikationen in den Metadaten ein.
  • In einigen Ausführungsformen ist die IoT-Steuerung 212 dafür konfiguriert, auf Grundlage eines Bildes oder Videos der Kabine 108 festzustellen, ob die Kabine 108 sauber oder schmutzig ist. Im Einzelnen betätigt die IoT-Steuerung 212 die Kameraauslöserschaltungen 278, um zu veranlassen, dass die Fahrzeugkamera 276 ein Bild oder Video der Kabine 108 aufnimmt, nachdem ein Fahrer oder Fahrgast das gemeinsam genutzte Fahrzeug 102 verlässt. Die IoT-Steuerung 212 führt einen Bildanalysealgorithmus, wie beispielsweise ein Maschinenlernmodell (z. B. ein künstliches neuronales Netz) aus, um das aufgenommene Bild oder Video zu analysieren, um Schmutz oder Verunreinigungen in dem gemeinsam genutzten Fahrzeug 102 zu erkennen. Schmutz kann verschiedene Formen annehmen, einschließlich von Staub, unterschiedlichen Arten von Erdreich, Verunreinigungen oder verstreuten Stücken von Abfall oder Überresten. Verbreitete Beispiele schließen Sand oder Gras auf dem Boden der Kabine 108, wie in 5 gezeigt, und Krümel oder andere Verunreinigungen auf dem Boden oder den Sitzen der Kabine 108, wie in 6 gezeigt, ein. Falls Schmutz oder Verunreinigungen erkannt werden, dann speichert die IoT-Steuerung 212 ein Schmutz- oder Verunreinigungsereignis in den Metadaten. In einer Ausführungsform modifiziert die IoT-Steuerung 212 das aufgenommene Bild oder Video, um den Schmutz oder die Verunreinigungen in dem aufgenommenen Bild oder Video zu markieren, wie beispielsweise mit Kästen 343, 346, wie in 5 und 6 gezeigt, und listet den Schmutz oder die Verunreinigungen ebenfalls in Metadaten des Bildes oder Videos auf. In einer Ausführungsform klassifiziert die IoT-Steuerung 212 den/die erkannten Schmutz oder Verunreinigungen (z. B. entfernbar/nicht entfernbar, Abfall, gefährlich, Flüssigkeit usw.), zum Beispiel unter Verwendung eines Maschinenlernmodells (z. B. eines künstlichen neuronalen Netzes), und schließt diese Klassifikationen in den Metadaten ein.
  • Zu 3 zurückkehrend, setzt sich das Verfahren 300 fort mit dem Hochladen wenigstens der Metadaten zu einem Cloudspeicher-Backend zum Speichern an demselben (Block 350). Im Einzelnen ist die IoT-Steuerung 212 dafür konfiguriert, das Mobilfunktelefonie-Modem derselben zu betätigen, um wenigstens die festgestellten Metadaten zu dem Cloudspeicher-Backend 150 hochzuladen. Die hochgeladenen Metadaten schließen wenigstens die erkannten Ereignisse ein und können entsprechende Zeitstempel, welche die Zeit angeben, zu der jedes Ereignis stattfand, sowie andere Kontextinformationen bezüglich der erkannten Ereignisse (z. B. ein als Reaktion auf das Erkennen eines Ereignisses aufgenommenes Bild) einschließen. In einigen Ausführungsformen ist die IoT-Steuerung 212 dafür konfiguriert, ebenfalls die Sensorrohdaten, aus denen ein Ereignis erkannt wurde, oder Zwischendaten, die während des Verarbeitens der Sensordaten, um ein Ereignis zu erkennen, bestimmt wurden, hochzuladen. In einigen Ausführungsformen ist die IoT-Steuerung 212 dafür konfiguriert, alle Sensorrohdaten hochzuladen, ungeachtet dessen, ob die Sensordaten irgendwelchen erkannten Ereignissen entsprechen. In einer Ausführungsform benutzt das fahrzeuginterne Sensormodul 112 eine gesicherte und verschlüsselte (TLS-V1.2-Verschlüsselung) Verbindung zu dem Cloudspeicher-Backend 150 unter Verwendung einer Infrastruktur mit öffentlichem Schlüssel (public key infrastructure - PKI) oder eines Äquivalents. In einer Ausführungsform wird die Authentifizierung durch Verwendung von Zertifikaten sichergestellt, die durch geeignete Zertifizierungsinstanzen unterzeichnet sind.
  • Cloudspeicher -Backend
  • Unter Bezugnahme auf 7 werden nun beispielhafte Komponenten des Cloudspeicher-Backends 150 beschrieben. Es wird zu erkennen sein, dass die hierin gezeigten und beschriebenen Komponenten des Cloudspeicher-Backends 150 nur beispielhaft sind und dass das Cloudspeicher-Backend 150 eine beliebige alternative Konfiguration aufweisen kann.
  • Wie in 4 gezeigt, umfasst das Ausführungsbeispiel des Cloudspeicher-Backends 150 einen oder mehrere Cloud-Server 400 und ein oder mehrere Cloud-Speichergeräte 420. Die Cloud-Server 400 schließen wenigstens einen oder mehrere Datenbankserver ein, die dafür konfiguriert sind, die Sensordaten, Ereignisdaten und/oder anderen Metadaten, die von dem fahrzeuginternen Sensormodul 112 empfangen und in den Cloud-Speichergeräten 420 gespeichert werden, zu verwalten. Außerdem können die Cloud-Server 400 ferner Server einschließen, die dafür konfiguriert sind, einer Vielzahl anderer Funktionen für das Cloudspeicher-Backend zu dienen, einschließlich von Webservern oder Anwendungsservern, in Abhängigkeit von den durch das Cloudspeicher-Backend 150 bereitgestellten Merkmalen. Jeder der Cloud-Server 400 schließt zum Beispiel einen Prozessor 402, einen Speicher 404, eine Benutzerschnittstelle 406 und ein Netzkommunikationsmodul 408 ein. Es wird zu erkennen sein, dass die illustrierte Ausführungsform der Cloud-Server 400 nur ein Ausführungsbeispiel eines Cloud-Servers 400 ist und nur repräsentativ für beliebige verschiedener Weisen oder Konfigurationen eines Arbeitsplatzrechners, Servers oder eines beliebigen anderen Datenverarbeitungssystems ist, das auf die hierin dargelegte Weise funktionsfähig ist.
  • Der Prozessor 402 ist dafür konfiguriert, Anweisungen auszuführen, um die Cloud-Server 400 zu betreiben, um die Merkmale, Funktionalität, Charakteristika und/oder dergleichen, wie hierin beschrieben, zu ermöglichen. Zu diesem Zweck ist der Prozessor 402 wirksam mit dem Speicher 404, der Benutzerschnittstelle 406 und dem Netzkommunikationsmodul 408 verbunden. Der Prozessor 402 schließt im Allgemeinen einen oder mehrere Prozessoren ein, die parallel oder auf andere Weise in Abstimmung miteinander arbeiten können. Es wird für die Durchschnittsfachleute zu erkennen sein, dass ein „Prozessor“ ein beliebiges Hardwaresystem, einen Hardwaremechanismus oder eine Hardwarekomponente einschließt, das/der/die Daten, Signale oder andere Informationen verarbeitet. Dementsprechend kann der Prozessor 402 ein System mit einer zentralen Verarbeitungseinheit, Grafikverarbeitungseinheiten, mehreren Verarbeitungseinheiten, dedizierten Schaltungen zum Erreichen von Funktionalität, programmierbarer Logik oder anderen Verarbeitungssystemen einschließen.
  • Die Cloud-Speichergeräte 420 sind dafür konfiguriert, Sensordaten, Ereignisdaten und/oder andere Metadaten, die von dem fahrzeuginternen Sensormodul 112 empfangen werden, zu speichern. Die Cloud-Speichergeräte 420 können von einer beliebigen Art von nicht-flüchtigem Langzeit-Speichergerät sein, das dazu in der Lage ist, für den Prozessor 402 zugängliche Informationen zu speichern, wie beispielsweise Festplattenlaufwerke oder beliebige von verschiedenen anderen rechnerlesbaren Speichermedien, die von Durchschnittsfachleuten anerkannt sind. Ebenso ist der Speicher 404 dafür konfiguriert, Programmanweisungen zu speichern, die, wenn sie durch den Prozessor 402 ausgeführt werden, ermöglichen, dass die Cloud-Server 400 verschiedene hierin beschriebene Operationen durchführen, einschließlich des Verwaltens der Sensordaten, Ereignisdaten und/oder anderen Metadaten, die in den Cloud-Speichergeräten 420 gespeichert werden. Der Speicher 404 kann von einer beliebigen Art von Gerät oder Kombination von Geräten sein, die dazu in der Lage ist, für den Prozessor 402 zugängliche Informationen zu speichern, wie beispielsweise Speicherkarten, ROM, RAM, Festplattenlaufwerke, Disks, Flash-Speicher oder beliebige von verschiedenen anderen rechnerlesbaren Medien, die von Durchschnittsfachleuten anerkannt sind.
  • Das Netzkommunikationsmodul 408 der Cloud-Server 400 stellt eine Schnittstelle bereit, die eine Kommunikation mit beliebigen von verschiedenen Geräten, wenigstens einschließlich des fahrzeuginternen Sensormoduls 112 ermöglicht. Im Einzelnen kann das Netzkommunikationsmodul 408 einen Lokalbereichsnetzanschluss einschließen, der eine Kommunikation mit beliebigen von verschiedenen lokalen Rechnern ermöglicht, die in der gleichen oder einer nahen Einrichtung untergebracht sind. Im Allgemeinen kommunizieren die Cloud-Server 400 über ein gesondertes Modem und/oder einen Router des Lokalbereichsnetzes über das Internat mit entfernten Rechnern. Alternativ kann das Netzkommunikationsmodul 408 ferner einen Weitbereichsnetzanschluss einschließen, der eine Kommunikation über das Internet ermöglicht. In einer Ausführungsform ist das Netzkommunikationsmodul 408 mit einem Wi-Fi-Sende-/Empfangsgerät oder einem anderen Drahtlos-Kommunikationsgerät ausgestattet. Dementsprechend wird zu erkennen sein, dass Kommunikationsverbindungen mit den Cloud-Servern 400 über drahtgebundene Kommunikationsverbindungen oder über die drahtlosen Kommunikationsverbindungen erfolgen kann. Kommunikationsverbindungen können unter Verwendung beliebiger von verschiedenen bekannten Kommunikationsprotokollen verwirklicht werden.
  • Die Cloud-Server 400 können lokal oder entfernt durch einen Administrator betrieben werden. Um den lokalen Betrieb zu erleichtern, können die Cloud-Server 400 eine Benutzerschnittstelle 406 einschließen. In wenigstens einer Ausführungsform kann die Benutzerschnittstelle 406 passenderweise einen LCD-Anzeigebildschirm oder dergleichen, eine Maus oder eine andere Zeigevorrichtung, eine Tastatur oder ein anderes Tastenfeld, Lautsprecher und ein Mikrofon einschließen, wie für Durchschnittsfachleute zu erkennen sein wird. Alternativ kann, in einigen Ausführungsformen, ein Administrator die Cloud-Server 400 entfernt von einem anderen Datenverarbeitungsgerät betreiben, das über ein Netzkommunikationsmodul 408 mit denselben in Kommunikation steht und eine analoge Benutzerschnittstelle aufweist.
  • Das Cloudspeicher-Backend 150 ist dafür konfiguriert, die Sensordaten, Ereignisdaten und/oder anderen Metadaten auf eine sichere Weise auf den Cloud-Speichergeräten 420 zu speichern und Zugriff auf die Sensordaten, Ereignisdaten und/oder anderen Metadaten durch Betreiber des Dienstes zur gemeinsamen Fahrzeugnutzung sowie andere autorisierte Dritte, über das Dritten-Backend 160 oder über eine Web-Schnittstelle oder API, die kontrollierte Zugangs- und Identitätsverwaltung einschließt, zu gewähren. Zu diesem Zweck steht, in wenigstens einigen Ausführungsformen, das Cloudspeicher-Backend 150 in bidirektionaler Kommunikation mit dem Dritten-Backend 160 des Diensteanbieters zur gemeinsamen Fahrzeugnutzung.
  • Betrieb des Cloudspeicher-Backends
  • Es wird unten eine Vielzahl von Verfahren und Prozessen zum Betreiben des Cloudspeicher-Backends 150 beschrieben. In diesen Beschreibungen beziehen sich Aussagen, dass ein Verfahren, Prozessor und/oder System eine Aufgabe oder Funktion durchführt, auf eine Steuerung oder einen Prozessor (z. B. den Prozessor 402 des Cloudspeicher-Backends 150), die/der programmierte Anweisungen ausführt, die in nicht-flüchtigen rechnerlesbaren Speichermedien (z. B. dem Speicher des Prozessors 402 des Cloudspeicher-Backends 150) gespeichert sind, die wirksam mit der Steuerung oder dem Prozessor verbunden sind, um Daten zu handhaben oder um eine oder mehrere Komponenten in dem Fahrzeugüberwachungssystem 100 zu betätigen, um die Aufgabe oder Funktion durchzuführen. Außerdem können die Schritte der Verfahren in einer beliebigen umsetzbaren chronologischen Reihenfolge durchgeführt werden, ungeachtet der in den Figuren gezeigten Reihenfolge oder der Reihenfolge, in der die Schritte beschrieben werden.
  • 8 zeigt ein Verfahren 500 zum Betreiben des Cloudspeicher-Systems 150, um Daten zu verwalten, die von mehreren fahrzeuginternen Sensormodulen 112 hochgeladen werden. Das Verfahren 500 ermöglicht es einem Betreiber eines Dienstes zur gemeinsamen Fahrzeugnutzung vorteilhafterweise, auf Metadaten bezüglich einer Überwachung von gemeinsam genutzten Fahrzeugen, die durch den Dienst zur gemeinsamen Fahrzeugnutzung verwendet werden, zuzugreifen. Auf diese Weise ermöglicht es das Verfahren 500 ermöglicht es Betreibern solcher Dienste zur gemeinsamen Fahrzeugnutzung vorteilhafterweise, mit minimalem menschlichen Eingreifen den Zustand der gemeinsam genutzten Fahrzeuge, in denen die mehreren fahrzeuginternen Sensormodule 112 eingebaut sind, zu überwachen, Regeln und Richtlinien durchzusetzen und Kunden zusätzliche Leistungen bereitzustellen.
  • Das Verfahren 500 beginnt mit dem Empfangen von Sensordaten und/oder Metadaten derselben von mehreren fahrzeuginternen Sensormodule, die jeweils in einem jeweiligen Fahrzeug eingebaut sind (Block 510). Im Einzelnen betätigt der Prozessor 402 des/der Cloud-Server(s) 400 des Cloudspeicher-Backends 150 das Netzkommunikationsmodul 408, um die Sensordaten und/oder Metadaten zu empfangen, die durch jedes von mehreren fahrzeuginternen Sensormodulen 112 hochgeladen werden, die in mehreren gemeinsam genutzten Fahrzeugen 102, wie beispielsweise denen einer Fahrzeugflotte eines Dienstes zur gemeinsame Fahrzeugnutzung, eingebaut sind. Wie oben bemerkt, geben die Metadaten an, ob verschiedene Bedingungen oder Ereignisse in Bezug auf das gemeinsam genutzte Fahrzeug 102, in dem das fahrzeuginterne Sensormodul 112 eingebaut ist, eingetreten sind oder nicht. Diese Metadaten werden durch jedes fahrzeuginterne Sensormodul 112 auf Grundlage von Sensordaten bestimmt, die durch die Sensoren jedes fahrzeuginternen Sensormoduls 112 erfasst werden.
  • Das Verfahren 500 setzt sich fort mit dem Speichern der Sensordaten und/oder Metadaten derselben in einer Datenbank in Verbindung mit dem fahrzeuginternen Sensormodul, von dem sie empfangen wurden (Block 520). Im Einzelnen speichert der Prozessor 402 die empfangenen Sensordaten und/oder Metadaten in einer Datenbank auf den Cloud-Speichergeräten 420 in Verbindung mit den bestimmten fahrzeuginternen Sensormodulen 112, von denen die Daten empfangen wurde. Wie hierin verwendet, bedeutet Daten „in Verbindung“ mit anderen Daten oder einem Konzept zu speichern, dass eine Beziehung oder Korrelation zwischen den Daten und den anderen Daten oder dem Konzept definiert wird, wie beispielsweise mit einem Identifizierungskennzeichen, einem Kopf, einer Tabelle, einem Kennzeichen, einem Index, einer Datenstruktur oder ähnlichen Technik. Zum Beispiel kennzeichnet oder verknüpft auf andere Weise der Prozessor 402, in einer Ausführungsform, die Sensordaten und/oder Metadaten in der Datenbank mit einer eindeutigen Kennung des bestimmten fahrzeuginternen Sensormoduls 11, von dem die Sensordaten und/oder Metadaten empfangen wurden, oder, gleichwertig, mit einer eindeutigen Kennung des gemeinsam genutzten Fahrzeugs 102, in dem die jeweiligen fahrzeuginternen Sensormodule 112 eingebaut sind, Auf diese Weise ist die Quelle für jeden Satz von Sensordaten und/oder Metadaten in der Datenbank identifizierbar.
  • Das Verfahren 500 setzt sich fort mit dem Übermitteln eine an ein Dritten-Backend als Reaktion darauf, dass die Metadaten angeben, dass ein(e) vorbestimmte(s) Bedingung oder Ereignis in Bezug auf ein bestimmtes Fahrzeug eingetreten ist (Block 530). Im Einzelnen sind, wie oben bemerkt, die fahrzeuginternen Sensormodule 112 dafür konfiguriert, Sensordaten zu verarbeiten, um das Eintreten verschiedener Bedingungen oder Ereignisse in Bezug auf das entsprechende gemeinsam genutzte Fahrzeug 102 zu erkennen. Die Metadaten schließen das Ergebnis dieser Verarbeitung ein und können zum Beispiel angeben, ob das gemeinsam genutzte Fahrzeug 102 an einem Zusammenstoß beteiligt gewesen ist oder auf andere Weise mechanisch beschädigt worden ist, ob die Kabine 108 des gemeinsam genutzten Fahrzeugs 102 einen unangenehmen oder unnormalen Geruch aufweist, ob ein Fahrer oder Fahrgast innerhalb der Kabine 108 des gemeinsam genutzten Fahrzeugs 102 raucht, ob Gegenstände durch Fahrgäste des gemeinsam genutzten Fahrzeugs 102 zurückgelassen worden sind, und ob die Kabine 108 des gemeinsam genutzten Fahrzeugs 102 sauber oder schmutzig ist.
  • Falls Metadaten angeben, dass ein(e) vorbestimmte(s) Bedingung oder Ereignis (wie beispielsweise die oben erwähnten) in Bezug auf das entsprechende gemeinsam genutzte Fahrzeug 102 eintrat, ist der Prozessor 402 dafür konfiguriert, als Reaktion auf das Empfangen der Metadaten, die angeben, dass die/das vorbestimmte Bedingung oder Ereignis eintrat, das Netzkommunikationsmodul 408 zu betätigen, um eine Warnnachricht an das Dritten-Backend 160 oder ein anderes entferntes Dritten-Datenverarbeitungsgerät (z. B. verknüpft mit einem Betreiber des Dienstes zur gemeinsamen Fahrzeugnutzung) zu übermitteln. In wenigstens einer Ausführungsform schließt die Warnnachricht (1) eine Angabe, welche(s) vorbestimmte Bedingung oder Ereignis eintrat, (2) einen Zeitstempel, wann die/das eingetretene vorbestimmte Bedingung oder Ereignis erkannt wurde, und (3) eine eindeutige Kennung der fahrzeuginternen Sensormodule 112, durch welche die/das vorbestimmte Bedingung oder Ereignis erkannt wurde, oder eine eindeutige Kennung des gemeinsam genutzten Fahrzeugs 102, in dem die/das vorbestimmte Bedingung oder Ereignis eintrat, ein. In einer Ausführungsform ist die Warnnachricht eine E-Mail.
  • Auf diese Weise wird, in dem Fall einer Regel- oder Richtlinienverletzung durch einen Kunden (z. B. einer Regel gegen Rauchen in dem gemeinsam genutzten Fahrzeug 102) der Betreiber des Dienstes zur gemeinsamen Fahrzeugnutzung unverzüglich benachrichtigt und kann Maßnahmen gegenüber dem Kunden ergreifen, wie beispielsweise durch Belegen des Kunden mit einer Geldstrafe oder Sperren desselben. Ähnlich kann der Betreiber des Dienstes zur gemeinsamen Fahrzeugnutzung Maßnahmen ergreifen, um den Zustand des gemeinsam genutzten Fahrzeugs 102 zu bessern (z. B. das gemeinsam genutzte Fahrzeug 102 zu Wartung, Reparatur oder Reinigung hereinholen) Schließlich kann ein Kunde im Fall eines verlorenen oder zurückgelassenen Gegenstandes unverzüglich informiert werden.
  • Das Verfahren 500 setzt sich fort mit dem Empfangen einer Anforderung von Sensordaten und/oder Metadaten derselben, die mit einem bestimmten Fahrzeug verknüpft sind, von dem Dritten-Datenverarbeitungsgerät (Block 540). Im Einzelnen ist, wie oben bemerkt, das Cloudspeicher-Backend dafür konfiguriert, Zugang zu den Sensordaten und/oder Metadaten durch Betreiber des Dienstes zur gemeinsamen Fahrzeugnutzung sowie andere autorisierte Dritte, über das Dritten-Backend 160 oder über eine Web-Schnittstelle oder eine Anwendungsprogrammierungsschnittstelle (application programming interface - API), die kontrollierte Zugangs- und Identitätsverwaltung einschließt, zu gewähren. Zu diesem Zweck betätigt der Prozessor 402 das Netzkommunikationsmodul 408, um eine Anforderungsnachricht zu empfangen, die Sensordaten und/oder Metadaten anfordert, die durch ein bestimmtes fahrzeuginternes Sensormodul 112 hochgeladen werden oder mit einem bestimmten gemeinsam genutzten Fahrzeug 102 verknüpft sind, Die Anforderungsnachricht kann von dem Dritten-Backend 160 oder von einem anderen autorisierten Dritten-Datenverarbeitungsgerät empfangen werden. Die Anforderungsnachricht identifiziert die eindeutige Kennung eines bestimmten fahrzeuginternen Sensormoduls 112 oder die eindeutige Kennung eines gemeinsam genutzten Fahrzeugs 102.
  • Das Verfahren 500 setzt sich fort mit dem Übermitteln, als Reaktion auf die Anforderung, der Sensordaten und/oder Metadaten derselben, die mit dem bestimmten Fahrzeug verknüpft sind, an das Dritten-Datenverarbeitungsgerät (Block 550). Im Einzelnen identifiziert der Prozessor 402 die Sensordaten und/oder Metadaten, die in der Datenbank der Cloud-Speichergeräte 420 gespeichert sind, die mit der eindeutigen Kennung eines bestimmten fahrzeuginternen Sensormoduls 112 oder der eindeutigen Kennung eines bestimmten gemeinsam genutzten Fahrzeugs 102 verknüpft sind, die in der Anforderung angegeben werden. Der Prozessor 402 des/der Cloud-Server(s) 400 des Cloudspeicher-Backends 150 betätigt dann das Netzkommunikationsmodul 408, um die identifizierten Sensordaten und/oder Metadaten an das Dritten-Backend 160 oder das andere autorisierte Dritten-Datenverarbeitungsgerät zu übermitteln oder die identifizierten Sensordaten und/oder Metadaten auf andere Weise für dieselben zugänglich zu machen.
  • Das Verfahren 500 setzt sich fort mit dem Empfangen einer Korrektur der mit dem bestimmten Fahrzeug verknüpften Metadaten von dem Dritten-Datenverarbeitungsgerät (Block 560). Im Einzelnen betätigt der Prozessor 402 des/der Cloud-Server(s) 400 des Cloudspeicher-Backends 150 das Netzkommunikationsmodul 408, um eine Korrekturnachricht zu empfangen, die eine Korrektur der Metadaten einschließt, die durch ein bestimmtes fahrzeuginternes Sensormodul 112 hochgeladen werden oder mit einem bestimmten gemeinsam genutzten Fahrzeug 102 verknüpft sind. Die Korrekturnachricht kann von dem Dritten-Backend 160 oder von einem anderen autorisierten Dritten-Datenverarbeitungsgerät empfangen werden. Die Korrekturnachricht identifiziert eine Modifikation oder Änderung an den Metadaten, die durch ein bestimmtes fahrzeuginternes Sensormodul 112 hochgeladen werden oder mit einem bestimmten gemeinsam genutzten Fahrzeug 102 verknüpft sind. Zum Beispiel können die Metadaten angeben, dass ein bestimmtes Ereignis eintrat, aber nach weiterer Überprüfung durch den Diensteanbieter zur gemeinsamen Fahrzeugnutzung könnte festgestellt werden, dass das Ereignis nicht stattfand. Die Korrektur kann einen korrigierten Wert für einen Teil der Metadaten einschließen. Alternativ kann die Korrektur einfach denjenigen Teil der Metadaten identifizieren, der unrichtig bestimmt wurde oder der auf andere Weise fehlerhaft ist, ohne einen korrigierten oder richtigen Wert bereitzustellen. Der Betreiber des Dienstes zur gemeinsamen Fahrzeugnutzung kann durch Bereitstellen einer Korrektur der Metadaten für das Cloudspeicher-Backend 150 eine Rückmeldung bereitstellen.
  • Das Verfahren 500 setzt sich fort mit dem Aktualisieren eines Modells, eines Algorithmus oder Schwellenwertes, die verwendet werden, um die Metadaten zu bestimmen, auf Grundlage der Korrektur der Metadaten (Block 570). Im Einzelnen benutzt, wie oben erwähnt, die IoT-Steuerung 212 der fahrzeuginternen Sensormodule 112 eine Vielzahl von Modellen, Algorithmen oder Schwellenwerten, um die Sensordaten zu verarbeiten und die Metadaten zu bestimmen. Als Reaktion auf das Empfangen einer Korrektur der Metadaten bestimmt der Prozessor 402 des/der Cloud-Server(s) 400 des Cloudspeicher-Backends 150 eine Aktualisierung oder Verfeinerung an einem oder mehreren dieser Modelle, Algorithmen oder Schwellenwerte. Als Nächstes betätigt der Prozessor 402 das Netzkommunikationsmodul 408, um die Aktualisierung oder Verfeinerung an dem einen oder den mehreren dieser Modelle, Algorithmen oder Schwellenwerte an jedes der fahrzeuginternen Sensormodule 112 zur Verwendung an denselben, wie zutreffend, zu übermitteln.
  • Ausführungsformen innerhalb des Rahmens der Offenbarung können ebenfalls nicht-flüchtige rechnerlesbare Speichermedien oder ein maschinenlesbares Medium zum Übertragen oder Aufweisen von rechnerausführbaren Anweisungen (auch als Programmanweisungen bezeichnet) oder Datenstrukturen, die auf denselben gespeichert sind, einschließen. Solche nicht-flüchtigen rechnerlesbaren Speichermedien oder ein maschinenlesbares Medium können beliebige verfügbare Medien sein, auf die durch einen Mehrzweck- oder Spezialrechner zugegriffen werden kann. Als Beispiel und nicht Beschränkung können solche nicht-flüchtigen rechnerlesbaren Speichermedien oder ein maschinenlesbares Medium RAM, ROM, EEPROM, CD-ROM oder andere optische Plattenspeicher-, magnetische Plattenspeicher- oder andere magnetische Speichergeräte, oder ein beliebiges anderes Medium umfassen, das verwendet werden kann, um Programmcodemittel in der Form von rechnerausführbaren Anweisungen oder Datenstrukturen zu übertragen oder zu speichern. Kombinationen der obigen sollten ebenfalls innerhalb des Rahmens der nicht-flüchtigen rechnerlesbaren Speichermedien oder des maschinenlesbaren Mediums eingeschlossen sein.
  • Rechnerausführbare Anweisungen schließen zum Beispiel Anweisungen und Daten ein, die veranlassen, dass ein Mehrzweckrechner, ein Spezialrechner oder ein Spezialdatenverarbeitungsgerät eine bestimmte Funktion oder Gruppe von Funktionen durchführt. Rechnerausführbare Anweisungen schließen ebenfalls Programmmodule ein, die durch Rechner in selbstständigen oder Netzumgebungen ausgeführt werden. Im Allgemeinen schließen Programmmodule Routinen, Programme, Objekte, Komponenten und Datenstrukturen usw. ein, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen umsetzen. Rechnerausführbare Anweisungen, zugeordnete Datenstrukturen und Programmmodule stellen Beispiele der Programmcodemittel zum Ausführen von Schritten der hierin offenbarten Verfahren dar. Die bestimmte Abfolge solcher ausführbarer Anweisungen oder zugeordneter Datenstrukturen stellt Beispiele entsprechender Handlungen zum Umsetzen der in solchen Schritten beschriebenen Funktionen dar.
  • Während die Offenbarung in den Zeichnungen und der vorstehenden Beschreibung ausführlich illustriert und beschrieben worden ist, sollten dieselben als von illustrativem und nicht einschränkendem Character betrachtet werden. Es versteht sich, dass nur die bevorzugten Ausführungsformen vorgestellt worden sind und dass gewünscht wird, alle Änderungen, Modifikationen und weiteren Anwendungen, die im Geist der Offenbarung erscheinen, zu schützen.

Claims (19)

  1. Verfahren zum Verwalten von Daten eines Fahrzeugüberwachungssystems, wobei das Fahrzeugüberwachungssystem mehrere Überwachungsvorrichtungen aufweist, wobei jede Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen in einem jeweiligen Fahrzeug eingebaut ist und wenigstens einen Sensor aufweist, der dafür konfiguriert ist, jeweilige Sensordaten zu erfassen, wobei das Verfahren Folgendes umfasst: Empfangen, an einem Server, von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, jeweiliger Metadaten, die angeben, ob wenigstens ein vorbestimmter Zustand des jeweiligen Fahrzeugs eingetreten ist, wobei die jeweiligen Metadaten durch die jeweilige Überwachungsvorrichtung auf Grundlage der jeweiligen Sensordaten festgestellt werden, Speichern, auf einem Speichergerät, das mit dem Server verbunden ist, für jede jeweilige Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, der jeweiligen Metadaten in Verbindung mit der jeweiligen Überwachungsvorrichtung, und Gewähren von Zugang zu den jeweiligen Metadaten, die von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen empfangen werden, durch wenigstens ein entferntes Datenverarbeitungsgerät.
  2. Verfahren nach Anspruch 1, das ferner Folgendes umfasst: Empfangen, an dem Server, von einer ersten Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, der jeweiligen Sensordaten, aus denen die jeweiligen Metadaten bestimmt wurden, Speichern, auf dem Speichergerät, für die erste Überwachungsvorrichtung, der jeweiligen Sensordaten in Verbindung mit der ersten Überwachungsvorrichtung, und Gewähren von Zugang zu den jeweiligen Sensordaten, die von der ersten Überwachungsvorrichtung empfangen werden, durch das wenigstens eine entfernte Datenverarbeitungsgerät.
  3. Verfahren nach Anspruch 1, wobei das Speichern ferner Folgendes umfasst: Speichern, auf dem Speichergerät, für jede jeweilige Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, der jeweiligen Metadaten in Verbindung mit wenigstens einem von (i) einer eindeutigen Kennung der jeweiligen Überwachungsvorrichtung und (ii) einer eindeutigen Kennung des jeweiligen Fahrzeugs, in dem die jeweilige Überwachungsvorrichtung eingebaut ist.
  4. Verfahren nach Anspruch 1, wobei das Gewähren von Zugang ferner Folgendes umfasst: Empfangen, an dem Server, von dem wenigstens einen entfernten Datenverarbeitungsgerät, einer Anforderungsnachricht, die wenigstens eines von (i) einer ersten Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen und (ii) dem jeweiligen Fahrzeug, in dem die erste Überwachungsvorrichtung eingebaut ist, identifiziert, und Übermitteln, mit dem Server, an das wenigstens eine entfernte Datenverarbeitungsgerät, der jeweiligen Metadaten, die von der ersten Überwachungsvorrichtung empfangen werden.
  5. Verfahren nach Anspruch 1, wobei das Gewähren von Zugang ferner Folgendes umfasst: Gewähren von Zugang zu den jeweiligen Metadaten, die von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen empfangen werden, über wenigstens eines von (i) einer Web-Schnittstelle und (ii) einer Anwendungsprogrammierungsschnittstelle.
  6. Verfahren nach Anspruch 1, das ferner Folgendes umfasst: Übermitteln, mit dem Server, einer Warnnachricht an das wenigstens eine entfernte Datenverarbeitungsgerät als Reaktion darauf, dass die jeweiligen Metadaten einer ersten Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen angeben, dass eine erste vorbestimmte Bedingung von der wenigstens einen vorbestimmten Bedingung des jeweiligen Fahrzeugs eingetreten ist.
  7. Verfahren nach Anspruch 6, wobei die Warnnachricht eine E-Mail-Nachricht ist.
  8. Verfahren nach Anspruch 6, wobei die Warnnachricht eine Zeit identifiziert, zu der die erste vorbestimmte Bedingung eintrat.
  9. Verfahren nach Anspruch 1, das ferner Folgendes umfasst: Empfangen, an dem Server, von dem wenigstens einen entfernten Datenverarbeitungsgerät, einer Nachricht, die eine Korrektur an den jeweiligen Metadaten angibt, die durch eine erste Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen empfangen wird, Bestimmen, mit dem Server, auf Grundlage der Korrektur, einer Aktualisierung für wenigstens eines von (i) einem Modell, (ii) einem Algorithmus und (iii) einem Schwellenwert, die durch die erste Überwachungsvorrichtung verwendet wurden, um die jeweiligen Metadaten auf Grundlage der jeweiligen Sensordaten zu bestimmen, und Übermitteln, mit dem Server, der Aktualisierung an die mehreren Überwachungsvorrichtungen.
  10. Verfahren nach Anspruch 9, wobei die Korrektur eine Angabe einschließt, dass die jeweiligen Metadaten unrichtig bestimmt wurden.
  11. Verfahren nach Anspruch 9, wobei die Korrektur einen korrigierten Wert für die jeweiligen Metadaten einschließt.
  12. Verfahren nach Anspruch 1, wobei die wenigstens eine vorbestimmte Bedingung des jeweiligen Fahrzeugs einschließt, dass das Rauchen eines Fahrgastes des jeweiligen Fahrzeugs innerhalb des Fahrzeugs erkannt wird.
  13. Verfahren nach Anspruch 1, wobei die wenigstens eine vorbestimmte Bedingung des jeweiligen Fahrzeugs einschließt, dass ein Geruch innerhalb des Fahrzeugs erkannt wird.
  14. Verfahren nach Anspruch 1, wobei die wenigstens eine vorbestimmte Bedingung des jeweiligen Fahrzeugs einschließt, dass ein Schaden an dem jeweiligen Fahrzeug erkannt wird.
  15. Verfahren nach Anspruch 1, wobei die wenigstens eine vorbestimmte Bedingung des jeweiligen Fahrzeugs einschließt, dass ein Zusammenstoß des jeweiligen Fahrzeugs erkannt wird.
  16. Verfahren nach Anspruch 1, wobei die wenigstens eine vorbestimmte Bedingung des jeweiligen Fahrzeugs einschließt, dass eine Unsauberkeit einer Kabine des jeweiligen Fahrzeugs erkannt wird.
  17. Verfahren nach Anspruch 1, wobei die wenigstens eine vorbestimmte Bedingung des jeweiligen Fahrzeugs einschließt, dass ein durch einen Fahrgast zurückgelassener Gegenstand erkannt wird.
  18. System zum Verwalten von Daten eines Fahrzeugüberwachungssystems, wobei der Server Folgendes umfasst: ein Sende/-Empfangsgerät, das dafür konfiguriert ist, mit mehreren Überwachungsvorrichtungen des Fahrzeugüberwachungssystems zu kommunizieren, wobei jede Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen in einem jeweiligen Fahrzeug eingebaut ist und wenigstens einen Sensor aufweist, der dafür konfiguriert ist, jeweilige Sensordaten zu erfassen, ein Speichergerät, das dafür konfiguriert ist, Daten zu speichern, die von den mehreren Überwachungsvorrichtungen empfangen werden, und einen Prozessor, der wirksam mit dem Sende/-Empfangsgerät und dem Speichergerät verbunden ist, wobei der Prozessor zu Folgendem konfiguriert ist: das Sende/-Empfangsgerät zu betätigen, um, von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, jeweilige Metadaten zu empfangen, die angeben, ob wenigstens ein vorbestimmter Zustand des jeweiligen Fahrzeugs eingetreten ist, wobei die jeweiligen Metadaten durch die jeweilige Überwachungsvorrichtung auf Grundlage der jeweiligen Sensordaten festgestellt werden, das Speichergerät zu betätigen, um, für jede jeweilige Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, die jeweiligen Metadaten in Verbindung mit der jeweiligen Überwachungsvorrichtung zu speichern, und das Sende/-Empfangsgerät und das Speichergerät zu betätigen, um Zugang zu den jeweiligen Metadaten, die von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen empfangen werden, durch wenigstens ein entferntes Datenverarbeitungsgerät zu gewähren.
  19. Nicht-flüchtiges rechnerlesbares Medium zum Verwalten von Daten eines Fahrzeugüberwachungssystems, wobei das Fahrzeugüberwachungssystem mehrere Überwachungsvorrichtungen aufweist, wobei jede Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen in einem jeweiligen Fahrzeug eingebaut ist und wenigstens einen Sensor aufweist, der dafür konfiguriert ist, jeweilige Sensordaten zu erfassen, wobei das rechnerlesbare Medium Programmanweisungen speichert, die, wenn sie durch einen Prozessor ausgeführt werden, veranlassen, dass der Prozessor: ein Sende/-Empfangsgerät betätigt, um, von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, jeweilige Metadaten zu empfangen, die angeben, ob wenigstens ein vorbestimmter Zustand des jeweiligen Fahrzeugs eingetreten ist, wobei die jeweiligen Metadaten durch die jeweilige Überwachungsvorrichtung auf Grundlage der jeweiligen Sensordaten festgestellt werden, ein Speichergerät betätigt, um, für jede jeweilige Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen, die jeweiligen Metadaten in Verbindung mit der jeweiligen Überwachungsvorrichtung zu speichern, und das Sende/-Empfangsgerät und das Speichergerät betätigt, um Zugang zu den jeweiligen Metadaten, die von jeder jeweiligen Überwachungsvorrichtung der mehreren Überwachungsvorrichtungen empfangen werden, durch wenigstens ein entferntes Datenverarbeitungsgerät zu gewähren.
DE102020215842.8A 2019-12-23 2020-12-14 Cloud-konnektivität für fahrzeuginterne sensormodule Pending DE102020215842A1 (de)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201962952618P 2019-12-23 2019-12-23
US201962952568P 2019-12-23 2019-12-23
US201962952623P 2019-12-23 2019-12-23
US62/952,623 2019-12-23
US62/952,618 2019-12-23
US62/952,568 2019-12-23

Publications (1)

Publication Number Publication Date
DE102020215842A1 true DE102020215842A1 (de) 2021-06-24

Family

ID=76206411

Family Applications (3)

Application Number Title Priority Date Filing Date
DE102020215842.8A Pending DE102020215842A1 (de) 2019-12-23 2020-12-14 Cloud-konnektivität für fahrzeuginterne sensormodule
DE102020215839.8A Pending DE102020215839A1 (de) 2019-12-23 2020-12-14 Fahrzeuginternes abtastmodul zur überwachung eines fahrzeugs
DE102020215840.1A Pending DE102020215840A1 (de) 2019-12-23 2020-12-14 Fahrzeuginternes sensormodul zum überwachen eines fahrzeugs

Family Applications After (2)

Application Number Title Priority Date Filing Date
DE102020215839.8A Pending DE102020215839A1 (de) 2019-12-23 2020-12-14 Fahrzeuginternes abtastmodul zur überwachung eines fahrzeugs
DE102020215840.1A Pending DE102020215840A1 (de) 2019-12-23 2020-12-14 Fahrzeuginternes sensormodul zum überwachen eines fahrzeugs

Country Status (3)

Country Link
US (3) US11875617B2 (de)
CN (3) CN113085758A (de)
DE (3) DE102020215842A1 (de)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110998273A (zh) * 2017-08-08 2020-04-10 福特全球技术公司 车辆检查系统和方法
KR20200124115A (ko) * 2019-04-23 2020-11-02 현대자동차주식회사 식별 디바이스를 활용하여 플릿 시스템을 제공하는 방법 및 장치
US11176149B2 (en) * 2019-08-13 2021-11-16 International Business Machines Corporation Predicted data provisioning for analytic workflows
US10803334B1 (en) * 2019-10-18 2020-10-13 Alpine Electronics of Silicon Valley, Inc. Detection of unsafe cabin conditions in autonomous vehicles
JP7367499B2 (ja) * 2019-12-06 2023-10-24 トヨタ自動車株式会社 車両、情報処理装置、及び情報処理方法
US11812124B2 (en) * 2020-01-22 2023-11-07 Ford Global Technologies, Llc Sensor assembly cover lock
US20210241926A1 (en) * 2020-01-31 2021-08-05 Splunk Inc. Sensor data device
JP7302533B2 (ja) * 2020-05-29 2023-07-04 トヨタ自動車株式会社 サーバ装置、情報処理システム、制御装置、乗合車両、及び情報処理システムの動作方法
US11794782B2 (en) * 2020-06-26 2023-10-24 Gm Cruise Holdings Llc Sensor aggregation module
US20220203886A1 (en) * 2020-12-29 2022-06-30 Lyft, Inc. Illuminated communication unit for a vehicle
US11926283B2 (en) 2022-01-06 2024-03-12 Ford Global Technologies, Llc Accelerometer wake-up
CN114619971B (zh) * 2022-05-17 2022-07-29 浙江华邦物联技术股份有限公司 一种物流车辆定位器的控制方法、定位器和可读存储介质
TR2022011598A2 (tr) * 2022-07-20 2022-08-22 Visucar Ileri Teknolojiler Yazilim Ve Danismanlik Sanayi Ticaret Anonim Sirketi Araç i̇çi̇ kamera veri̇leri̇ni̇n anali̇zi̇ne yöneli̇k bi̇r yöntem ve si̇stem
CN115185323A (zh) * 2022-09-08 2022-10-14 苏州洪昇新能源科技有限公司 一种新能源设备远程管控方法及系统

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE2310979A1 (de) 1973-03-06 1974-09-12 Becker Karl Masch Zellenrad zum vereinzeln und verteilen von koernigem gut
JP3936154B2 (ja) * 2001-06-29 2007-06-27 小島プレス工業株式会社 車載用コントロールモジュール
US7440845B1 (en) 2003-03-26 2008-10-21 Garmin Ltd. Navigational device for installation in a vehicle and a method for doing same
CN1815398A (zh) * 2005-02-03 2006-08-09 刘彤浩 具有内部外部两组传感器的智能环境调节装置
US7889086B2 (en) 2007-09-28 2011-02-15 Hella Kgaa Camera arrangement in a motor vehicle
US10977727B1 (en) * 2010-11-18 2021-04-13 AUTO I.D., Inc. Web-based system and method for providing comprehensive vehicle build information
US20120324018A1 (en) * 2011-06-16 2012-12-20 Yahoo! Inc. Systems and methods for location based social network
DE112012003221B4 (de) 2011-08-02 2022-11-10 Magna Electronics, Inc. Fahrzeugkamerasystem und Verfahren zum Zusammenbau eines Fahrzeugkamerasystems
WO2013100902A1 (en) * 2011-12-27 2013-07-04 Intel Corporation Method, system, and device for to-do-list based navigation
US9602779B2 (en) 2012-07-10 2017-03-21 Christopher DeJuliis System for passenger monitoring
US8954204B2 (en) 2013-03-22 2015-02-10 General Motors Llc Collision sensor, collision sensing system, and method
US20150371456A1 (en) 2014-06-24 2015-12-24 Hertz System, Inc. System and Method for Detecting and Remotely Assessing Vehicle Incidents and Dispatching Assistance
US9688194B2 (en) 2015-03-26 2017-06-27 Ford Global Technologies, Llc In-vehicle particulate sensor data analysis
CN104972870A (zh) * 2015-07-03 2015-10-14 西华大学 一种汽车车内空气质量监测及净化调节系统
DE102015212923A1 (de) * 2015-07-10 2017-01-12 Bayerische Motoren Werke Aktiengesellschaft Automatische Erkennung und Bewertung von Low-Speed-Crashs
US10196070B2 (en) 2016-07-26 2019-02-05 Faraday & Future Inc. Safety and clean vehicle monitoring system
WO2018049527A1 (en) * 2016-09-14 2018-03-22 Campbell Scientific Canada Corp. Systems and related methods for providing environmental intelligence
DE102017200355A1 (de) * 2017-01-11 2018-07-12 Robert Bosch Gmbh Kraftfahrzeug mit einer Vorrichtung zur luftschallakustischen Sensierung der Umgebung des Kraftfahrzeugs
US10252688B2 (en) 2017-03-22 2019-04-09 Ford Global Technologies, Llc Monitoring a vehicle cabin
US10445950B1 (en) 2017-03-27 2019-10-15 Uber Technologies, Inc. Vehicle monitoring system
US11367346B2 (en) * 2017-06-07 2022-06-21 Nexar, Ltd. Digitizing and mapping the public space using collaborative networks of mobile agents and cloud nodes
CN107199845B (zh) * 2017-06-12 2018-07-06 吉林大学 一种驾驶室内环境主动控制系统及其控制方法
US20180365771A1 (en) * 2017-06-15 2018-12-20 Flex Ltd. Systems and methods for assessing the insurance risk of driver behavior using gps tracking and machine learning
CN107415602A (zh) 2017-07-06 2017-12-01 上海小蚁科技有限公司 用于车辆的监测方法、设备和系统、计算机可读存储介质
US10286751B2 (en) 2017-07-06 2019-05-14 Ford Global Technologies Llc Energy saving offset strategy for autonomous vehicle passenger cabin
US11106927B2 (en) 2017-12-27 2021-08-31 Direct Current Capital LLC Method for monitoring an interior state of an autonomous vehicle
KR102534209B1 (ko) * 2018-01-25 2023-05-17 엘지전자 주식회사 차량용 업데이트 시스템 및 제어 방법
US11729270B2 (en) * 2018-01-29 2023-08-15 Uber Technologies, Inc. Autonomous vehicle application programming interface and communications systems and methods
CA3087506A1 (en) * 2018-01-31 2019-08-08 Xirgo Technologies, Llc Enhanced vehicle sharing system
US20190263217A1 (en) * 2018-02-26 2019-08-29 Ford Global Technologies, Llc Vehicle console assembly
JP6662935B2 (ja) * 2018-03-09 2020-03-11 本田技研工業株式会社 車両制御装置、車両制御方法、およびプログラム
WO2019180700A1 (en) * 2018-03-18 2019-09-26 Liveu Ltd. Device, system, and method of autonomous driving and tele-operated vehicles
US10223844B1 (en) 2018-09-18 2019-03-05 Wesley Edward Schwie Self-driving vehicle systems and methods
US11043044B2 (en) * 2018-12-04 2021-06-22 Blackberry Limited Systems and methods for vehicle condition inspection for shared vehicles
US10951728B2 (en) * 2019-02-11 2021-03-16 Blackberry Limited Proxy for access of a vehicle component
US11893527B2 (en) * 2019-09-24 2024-02-06 Toyota Motor North America, Inc. System and method for returning lost items
US11032372B1 (en) * 2019-10-14 2021-06-08 Lytx. Inc. Efficient data streaming using a global index

Also Published As

Publication number Publication date
DE102020215839A1 (de) 2021-06-24
US11875617B2 (en) 2024-01-16
US20210190516A1 (en) 2021-06-24
CN113091799A (zh) 2021-07-09
US11776332B2 (en) 2023-10-03
CN113085758A (zh) 2021-07-09
CN113085756A (zh) 2021-07-09
DE102020215840A1 (de) 2021-06-24
US20210194960A1 (en) 2021-06-24
US11704947B2 (en) 2023-07-18
US20210192871A1 (en) 2021-06-24

Similar Documents

Publication Publication Date Title
DE102020215842A1 (de) Cloud-konnektivität für fahrzeuginterne sensormodule
DE102013209055A1 (de) Datenquellenidentifizierung, Datensammlung und Datenspeicherung für Verkehrsereignisse
DE102017125484A1 (de) System und verfahren zum einschätzen des innenraums eines autonomen fahrzeugs
DE102018118846A1 (de) Verhinderung der Verschmutzung von Fahrzeugkameras und -sensoren
DE102018132509A1 (de) Ein Fahrzeug und ein Verfahren zur fahrzeugübergreifenden Zusammenarbeit zur Erfassung von physischer äußerlicher Beschädigung
DE102017125421A1 (de) Objektklassifikationsanpassung anhand einer fahrzeugkommunikation
DE102018117910A1 (de) Überwachungssytem für eine Ladestationsparklücke für Elektrofahrzeuge
DE102018102285A1 (de) System und verfahren zum beurteilen des innenraums eines autonomen fahrzeugs
DE102014211987A1 (de) Kameraaktivitätssystem
DE102015113644A1 (de) Vorrichtung und system zum erzeugen von fahrzeugnotfallaufzeichnungsdaten
DE102018109123A1 (de) Steuermodulaktivierung von Fahrzeugen in einem Zustand mit ausgeschalteter Zündung
DE112012004771T5 (de) Verfahren und System zur Fahrzeugdatensammlung hinsichtlich Verkehr
DE102019115693A1 (de) Auslöserbasierte fahrzeugüberwachung
DE102016121893A1 (de) Verfahren und Vorrichtung für Warnungen über interne/externe Fahrzeugumgebung
DE102017121523A1 (de) Integrierte fahrzeuginterne Datensammlung
DE102018112148A1 (de) Verfolgen von unfallfluchttätern mithilfe von v2x-kommunikation
DE102018109110A1 (de) Steuermodulaktivierung von fahrzeugen in einem zustand mit ausgeschalteter zündung zum ermitteln von fahrtrouten
DE102018128278A1 (de) Leitfahrzeugüberwachung für eine adaptive geschwindigkeitsregelung
DE102019133268A1 (de) Auslöserbasierte boni mit blockchain für fahrzeugflotte
DE102018106818A1 (de) Verfahren und vorrichtung für die fahrzeugsystemverschleissvorhersage
DE102020104551A1 (de) Sicherung und wiederherstellung einer fahrzeugsteuerungskonfiguration unter verwendung von datenschnappschüssen
DE102021132366A1 (de) Systeme und verfahren zum reinigen einer anzeige in einem fahrzeug
DE102020100734A1 (de) Fahrzeugdatenmomentaufnahme für flott
DE102020207488A1 (de) System und Verfahren zur Handhabung eines verloren gegangenen Gegenstands in einem autonomen Fahrzeug
DE112020005622T5 (de) Informationsverarbeitungsvorrichtung, Informationsverarbeitungsverfahren und Programm

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: ISARPATENT - PATENT- UND RECHTSANWAELTE BARTH , DE