HAR-Kameraansicht

Behörden haben mehrere Anforderungen eingeführt, um sicherzustellen, dass die indirekte Sicht nach hinten genügend Informationen für präzise und rechtzeitige Fahrmanöver liefert. Das wirkt sich auf die Wahrnehmung der Umgebung durch den Fahrer aus.

Für Rückfahrkamerasysteme, die auf dem Camera Monitoring System (CMS) basieren, schreibt die National Highway Traffic Safety Administration (NHTSA) vor, dass Sie die folgenden Anforderungen erfüllen (S6.6.2.3, bezogen auf UNECE46):

  • S5.5.3 Reaktionszeit. Das Rückfahrkamera-Bild, das den Anforderungen von S5.5.1 (Sichtfeld) und S5.5.2 (Größe) entspricht, wird bei Tests gemäß S14.2 innerhalb von 2,0 Sekunden nach Beginn eines Rückfahrereignisses angezeigt.

  • S5.5.4 Verweilzeit. Das Rückfahrbild, das den Anforderungen von S5.5.1 und S5.5.2 entspricht, wird nach dem Ende des Rückfahrvorgangs nicht angezeigt.

  • S5.5.5 Deaktivierung. Das Rückfahrbild, das den Anforderungen von S5.5.1 und S5.5.2 entspricht, bleibt während des Rückfahrvorgangs sichtbar, bis der Fahrer die Ansicht ändert oder der Richtungshebel des Fahrzeugs aus der Rückwärtsposition bewegt wird.

  • S6.6.2.3.3.5 Artefakte. In der Bedienungsanleitung des Geräts sollte auf mögliche Artefakte und deren Auswirkungen auf die teilweise Verdeckung des Sichtfelds und der Objekte hingewiesen werden, die den Fahrer zu besonderer Wachsamkeit und Aufmerksamkeit auffordern können.

  • S6.2.2.3.4.1 Framerate. Bewegungen von Objekten vor der Kamera werden flüssig dargestellt. Die Mindestbildrate des Systems beträgt mindestens 30 Hz (entspricht 30 fps). Bei schlechten Lichtverhältnissen oder beim Manövrieren mit niedriger Geschwindigkeit beträgt die Mindestbildrate des Systems mindestens 15 Hz.

  • S6.2.2.3.4.2 Zeit für die Bildgenerierung. Die Bildaufbauzeit des Monitors beträgt bei einer Temperatur von 22 °C ± 5 °C weniger als 55 ms.

  • S6.2.2.3.4.3 Systemlatenz. Ein Kamera-Monitorsystem (CMS) hat eine ausreichend kurze Latenz, um die Umgebung nahezu gleichzeitig darzustellen. Die Latenz liegt bei einer Temperatur von 22 °C ±5 °C unter 200 ms.

Wir haben das Extended View System (EVS) für Android Automotive OS (AAOS) eingeführt, um diese Anforderungen auf Bare-Metal-AAOS zu erfüllen. Wir haben einen ähnlichen Dienst für die Virtualisierung auf AAOS-Geräten mit dem Hochverfügbarkeits-Renderer (HAR) eingeführt, der ebenfalls die Einhaltung dieser Anforderungen demonstriert.

Pipeline für die Kameravorschau

Diese fünf Phasen bilden die Pipeline für die Kameravorschau:

Pipeline-Phasen für die Kameravorschau

Abbildung 1. Pipeline-Phasen der Kameravorschau.

Camera Service Block bezieht sich auf die Camera Service-Plattform und ihre Abstraktionsebene, über die Apps auf verfügbare Kameras zugreifen und diese nutzen können. Die Funktion „Display Service“ visualisiert die Bilddaten für Nutzer. Die App implementiert die Zielnutzer-Journeys mit dem Kamera- und dem Displaydienst.

Der primäre Ablauf für die Sicht nach hinten ist:

  1. Der Fahrer legt den Richtungshebel (den Gang) auf „Rückwärts“, um ein Rückwärtsfahrereignis auszulösen.

  2. Das System überträgt das Sicherungsereignis. Die App empfängt den Broadcast und initialisiert den Kameraeingabeblock (Camera Service) und den Renderer (Display Service).

  3. Der Kameraeingabeblock initialisiert die Camera Service-Plattform und gibt das Service-Handle an die App zurück.

  4. Der Renderer initialisiert das Ansichtsfenster für die Kameraeingabe aus Schritt 4.

  5. Die App fordert den Kameraeingabeblock auf, mit dem Senden von Frame-Puffern und Ereignissen zu beginnen.

  6. Die App stellt über die Callbacks (asynchron) gelieferte Frame-Puffer in die Warteschlange. Framebuffer gehören zum Kameraeingabeblock, daher kann die App sie nicht ändern.

  7. Die App entfernt einen Frame-Puffer aus der Warteschlange (falls die Warteschlange nicht leer ist) und stellt die Ansicht für den Nutzer zusammen. Nutzer können eine Kopie erstellen, um die Inhalte zu bearbeiten.

  8. Die App sendet einen Puffer an den Renderer.

  9. Der Renderer zeichnet den Inhalt eines empfangenen Puffers auf dem Display.

  10. Wenn das Sicherungsereignis noch läuft, fahren Sie mit Schritt 7 fort. Wenn das zugrunde liegende Ereignis abgeschlossen ist, fordert die App den Kameraeingabeblock auf, keine Framepuffer und Ereignisse mehr zu senden, nachdem die Ansicht für den Nutzer ausgeblendet wurde.

  11. Die App schließt optional eine Kamera und gibt den Renderer frei.

Abbildung 1 veranschaulicht den Ablauf. Dieses Bild verwendet Elemente aus der QNX Camera Library API, um die Camera Service-Plattform zu nutzen.

HAR-Hauptnutzerprozess

Abbildung 2: HAR-Hauptnutzerverhalten.

Im Kameraeingabeblock werden drei Schnittstellen deklariert:

  • CameraManager deklariert Methoden zum Verwalten von Kamerageräten. Die App verwendet diese Schnittstelle beispielsweise, um ein Zielkameragerät zu öffnen (zu reservieren).

  • In CameraDevice werden Methoden zum Steuern eines Kamerageräts deklariert, z. B. zum Starten oder Beenden eines Datenstreams.

  • CameraStreamListener deklariert eine einzelne Methode zum Empfangen verschiedener Ereignisse von einer Zielkamera.

Design

In diesem Abschnitt wird das Systemdesign beschrieben.

Nutzererfahrung

Der Fahrer kann sich das Bild der Rückfahrkamera auf dem Kombiinstrument ansehen, wenn er den Rückwärtsgang einlegt. Die Kamera wird nicht mehr auf dem Display angezeigt, wenn der Fahrer den Rückwärtsgang verlässt.

Es können zusätzliche Nutzeraktionen aktiviert werden. So kann der Fahrer beispielsweise den Bereich, der in den Spiegeln nicht sichtbar ist, in der Vorschau ansehen, wenn der Blinker aktiviert ist.

Kameravorschau starten

Bei der Verwendung von Kameras listet die App verfügbare Kameras auf und bewertet sie, um die beste Kamera für den jeweiligen Zweck zu finden. Für die Sicht nach hinten sucht die App beispielsweise in der Liste der verfügbaren Kameras nach der Kamera, die die Rückseite des Fahrzeugs zeigt.

Dazu werden die Eigenschaften jeder Kamera untersucht, z. B. Position, Ausrichtung des Objektivs, Framerate, Ausgaberesolution und Ausgabeformat. Wenn mehrere Kameras dieselben erforderlichen Eigenschaften haben, untersucht die App möglicherweise zusätzliche Eigenschaften wie das Sichtfeld und die Brennweite.

Dieses Bild zeigt eine Sequenz zum Starten einer Kameravorschau mit einer statischen Kamerakonfiguration:

Kameravorschau mit statischer Kamerakonfiguration starten

Abbildung 3: Kameravorschau mit statischer Kamerakonfiguration starten.

Kameravorschau beenden

Die App bietet keine Sicht nach hinten mehr, wenn das Rückwärtsfahren beendet ist. Damit entweder ein leerer Bildschirm oder ein Standbild angezeigt wird, blendet die App die Ansicht zuerst für den Nutzer aus und fordert dann an, dass der Kameraeingabeblock keine Ereignisse mehr sendet.

Dieses Bild zeigt eine Sequenz zum Beenden eines Datenstreams von einem Zielkameragerät:

Datenstream von der Zielkamera beenden

Abbildung 4: Beenden Sie den Datenstream vom Zielkameragerät.

Fehler

Ein Kameragerät kann unerwartet aufhören, einen neuen Framebuffer zu senden. Um solche Vorfälle zu erkennen, kann der Kameraeingabeblock einen Timer implementieren, der beim Eintreffen eines neuen Frames abläuft und eine Benachrichtigung sendet, wenn dieser Timer abläuft.

Wenn die App eine Benachrichtigung erhält, wird der Nutzer darüber informiert, dass der Kameravorschaubild nicht mehr live ist. Die App versucht, den Kameravorschaubild wiederherzustellen, indem sie ein Kameragerät schließt und wieder öffnet. Abbildung 5 zeigt, wie die App ein Zeitlimit behandelt:

Umgang mit Zeitüberschreitungen

Abbildung 5: Timeout (hängender Datenstream) behandeln

Der Kameraeingabeblock kann auch andere Vorfälle als einen hängenden Datenstream melden und weitere Details in die Puffer einbetten. OEMs können diese Ereignismetadaten verwenden, um Vorfälle auf ihrer Plattform zu bearbeiten.

Aktivitäten

Die API wird von Apps verwendet, die auf dem Host ausgeführt werden und das Kombiinstrument über die HAR (blaue Blöcke im Diagramm unten) verwalten.

Ein Systemdiagramm ist in Abbildung 5 dargestellt:

Systemdiagramm

Abbildung 6. Systemdiagramm.

Dienste

API-Aufrufe sollten im Kontext des aufrufenden Prozesses ausgeführt werden.

APIs

Die neue API ist nur für Apps vorgesehen, die die Kameravorschaubilder auf dem Kombiinstrument über den HAR verwalten. Die API ist über die Plattformabstraktionsschicht verfügbar und wird dynamisch verknüpft.

Die CameraInputBlock-Schnittstelle deklariert Methoden zum Initialisieren der Kamerafunktionen und zum Abrufen des Eingabeblock-Managers. Die App verwendet eine zurückgegebene CameraManager-Instanz, um Kamerageräte zu verwalten.

// This class represents a camera input block for the application that manages the
// instrument cluster display with Harry.
public class CameraInputBlock : public InputBlock {
    public:
        // Clean up the resources.
        virtual ~CameraInputBlock();

        // A method inherited from InputBlock class. This method initializes
        // CameraInputBlock instance; e.g. checking the platform camera service
        // is live.
        //
        // @return CAMERA_EPERM if the platform camera service is not
        //                      available.
        //         CAMERA_OK otherwise.
        virtual CameraError init() override;

        // A method inherited from InputBlock class. This method release all
        // resources held by this CameraInputBlock instance.
        virtual void release() override;

        // This method returns a CameraManager instance. The caller uses
        // this instance to manage camera devices.
        //
        // @param out If this method is successful, this points to a valid
        //            CameraManager instance.
        // @return CAMERA_EACCESS when we fail to create CameraManager instance
        //         to return.
        //         CAMERA_OK otherwise.
        virtual CameraError getCameraManager(
            std::shared_ptr<CameraManager>* out) = 0;

    private:
        // Handle to manage camera devices.
        std::shared_ptr<CameraManager> mMgr;

        // Handle to manage camera devices that have been opened by clients.
        std::set<CameraDevice> mCameras;
};

In der Klasse CameraManager werden Methoden zum Öffnen (oder Besitzen) von Kameras deklariert und freigegeben, wenn die App die Kamera nicht mehr benötigt. Die App kann mehr als eine Kamera öffnen und deren Streams nutzen, um ein breiteres Sichtfeld oder eine Multiview-Ansicht zu erstellen.

// This pure virtual class declares methods to manage camera devices.
public class CameraManager {
    public:
        // This method returns a list of CameraDescriptor objects representing
        // available cameras.
        //
        // @param out A list of CameraDescriptor instances. This list may be
        //            empty if the platform camera service does not list any
        //            camera.
        // @return CAMERA_EACCESS if we failed to build a camera list.
        //         CAMERA_OK otherwise.
        virtual CameraError getCameraList(
            std::vector<CameraDescriptor>* out) = 0;

        // Open a camera device associated with a given string identifier.
        //
        // @param ID A string identifier of a camera device to request.
        // @param out A pointer to CameraDevice shared pointer object. This
        //            is null when we fail to open a target device.
        // @return CAMERA_ENODEV if no camera is associated with a given id.
        //         CAMERA_EACCESS if it fails to open a target device.
        //         CAMERA_OK otherwise.
        virtual CameraError open(
            std::string ID, std::shared_ptr<CameraDevice>* out) = 0;

        // Close a camera device associated with a given string identifier.
        // This method is assumed to be always successful.
        //
        // @param id A string identifier of a camera device to close.
        virtual void close(std::string id) = 0;
};

Wenn Apps nicht erkennen können, welche Kameras verwendet werden sollen, können sie die Kamera auswählen, die im jeweiligen Kontext am besten funktioniert. CameraManager::getCameraList() gibt eine Liste von CameraDescriptor-Instanzen zurück, die die Merkmale jeder Kamera enthalten.

Die Klasse CameraDevice stellt ein einzelnes Kameragerät dar und deklariert Methoden zum Starten und Beenden des zugehörigen Datenstreams. Wenn die Kameraeigenschaften nicht statisch bekannt sind, rufen Clients sie aus dem Deskriptor ab und parsen sie.

Ein Client kann beispielsweise aus den Metadaten einer Zielkamera eine Liste der Streamkonfigurationen abrufen, die sie bietet, und die Konfiguration mit den besten Attributen (z. B. Bildraten, Auflösungen und Ausgabeformat) auswählen.

// This class represents a single camera device.
public class CameraDevice {
    public:
        // Start a data stream that attributes are matching to given
        // configuration best.
        // If a selected configuration is not given (null), a data stream is
        // initiated in its default configuration and return.
        //
        // @param configuration Selected attributes of the imagery data stream.
        // @param listener An object to listen to an active data stream.
        // @param effective Actual attributes of started data stream.
        // @return CAMERA_EINVAL if a listener object is invalid.
        //         CAMERA_EIO if we failed to start a video stream.
        //         CAMERA_OK otherwise.
        virtual CameraError start(
                std::shared_ptr<CameraStreamConfiguration>& configuration,
                std::shared_ptr<CameraStreamListener>& listener,
                std::shared_ptr<CameraStreamConfiguration>* effective) = 0;

        // Stop a data stream.
        virtual void stop() = 0;

        // Get a camera descriptor.
        //
        // @param desc A set of attributes that defines this camera device.
        // @return CAMERA_ENODATA if a descriptor is not available.
        //         CAMERA_OK otherwise.
        CameraError getDescriptor(std::shared_ptr<CameraDescriptor>* desc) = 0;

        // Return a consumed buffer to the camera device. A client of active
        // stream must return a frame buffer explicitly by calling this method.
        virtual void doneWithFrame(std::shared_ptr<FrameBuffer>& buffer) = 0;

    private:
        // Describe this camera device.
        CameraDescriptor mDescriptor;

        // A weak reference to a listening client.
        std::weak_ptr<CameraStreamListener> mClient;
};

// This class declares attributes that characterize a camera device.
public class CameraDescriptor {
    public:
        // Unique std::string object to identify a single camera device.
        std::string mId;

        // A set of stream configurations this camera device is capable of. A
        // camera must have at least one stream configuration.
        std::set<CameraStreamConfiguration> mConfigurations;

        // Are more attributes needed to exist, such as locations, lens
        // facing directions, and intrinsic/extrinsic parameters?
};

// This class declares attributes that characterize an imagery data stream.
public class CameraStreamConfiguration {
    public:
        // Width of output of this stream in pixels.
        unsigned int mWidthInPixels;

        // Height of output of this stream in pixels.
        unsigned int mHeightInPixels;

        // An average number of frames per second.
        double mFrameRate;

        // A format of this stream's output. A client could calculate a
        // byte-per-pixel (bpp) from this.
        CameraColorFormat mFormat;
};

// This class represents a listener/callback object to listen to frames and
// events.
public class CameraStreamListener {
    public:
        // A listener method to receive various stream events including a new
        // frame buffer.
        //
        // @param event CameraStreamEvent object that represents a single event
        //              such as an arrival of a new frame buffer, camera stream
        //              is terminated, and so forth.
        virtual void onEvent(std::shared_ptr<CameraStreamEvent>* event) = 0;
};

CameraDevice::start() verwendet drei Argumente:

  • Vom Anrufer ausgewählte Streamkonfiguration.

  • Listener, der Stream-Ereignisse empfängt.

  • Zeiger auf eine effektive Streamkonfiguration. Wir empfehlen dringend, dass der Aufrufer diesen Wert prüft, um ankommende Framebuffer wie vorgesehen zu verarbeiten.

Wenn CameraDevice::start() einen Datenstream mit der Camera Service-Plattform startet, wird eine schwache Referenz auf das Listener-Objekt des Aufrufers beibehalten, um das unerwartete Beenden des Aufrufers zu erkennen.

Wenn ein Client einen Framebuffer nicht mehr benötigt, muss er das Kameragerät darüber informieren, indem er die Methode CameraDevice::doneWithFrame() aufruft.

Wenn ein Stream gestartet wird, empfängt ein Client Ereignisnachrichten. Eine häufige Nachricht ist ein neuer Framebuffer. Über eine registrierte Callback-Funktion empfängt ein Client ein kNewFrameBuffer-Ereignis, das die Bilddaten zusammen mit den Framebuffer-Metadaten enthält. In StreamEventType werden weitere Typen deklariert, um andere Streamereignisse zu verarbeiten. z. B. ein angehaltener oder hängender Datenstream.

// This class lists events possibly occurring while a data stream is active.
enum class CameraStreamEventType {
    // A delivery of a new frame buffer.
    kNewFrameBuffer,
    // A data stream has been stopped.
    kStreamStopped,
    // No new frame buffer arrives for a while.
    kStreamHang,
    // Add more.
    ...
};

// This class represents a single instance of StreamEventType.
public class CameraStreamEvent {
    public:
        // Return a type of this event.
        //
        // @return CameraStreamEventType enum value.
        CameraStreamEventType getType() { return mType; }

        // Return a pointer to data associated with this event.
        //
        // @return A shared pointer object of the buffer that contains data for
        //         this event.
        std::shared_ptr<void> getData() { return mData; }

    private:
        // Describe a type of this event.
        CameraStreamEventType mType;

        // A pointer to the data buffer.
        std::shared_ptr<void> mData;
};

// This class inherits StreamEvent class and has additional fields to represent
// the frame buffer.
public class FrameBufferEvent : public CameraStreamEvent {
    public:
        // Return an identifier of this frame buffer.
        //
        // @return A unique integer value to identify this frame buffer.
        int getBufferID() { return mBufferID; }

        // Give access to frame buffer metadata.
        //
        // @return A shared pointer to the buffer that contains data besides
        //         the imagery data.
        std::shared_ptr<void> getMetadata() { return mMetadata; }

    private:
        // Unique integer to identify this buffer.
        int mBufferID;

        // A pointer to metadata of this frame buffer.
        std::shared_ptr<void> mMetadata;
};

In diesem Beispiel wird eine Implementierung der CameraInputBlock-Schnittstelle und der zugehörigen App gezeigt:

CameraError getCameraManager(std::shared_ptr<CameraManager>* out) {
    // During an instantiation, CameraManager will retrieve a list of camera
    // devices from the platform camera service and identify their attributes.
    *out = std::make_shared<CameraManager>();
    return CAMERA_OK;
}

// This method returns a list of CameraDescriptor objects representing available
// cameras.
CameraError CameraManager::getCameraList(std::vector<CameraDescriptor>* out) {
    if (mCameraList.size() < 1) {
        // Query a list of cameras and get their attributes.
    }
    *out = mCameraList;
    return CAMERA_OK;
}

// Open a camera device associated with a given string identifier.
CameraError CameraManager::open(std::string id, std::shared_ptr<CameraDevice>* out) {
    if (!mCameraList.contains(id)) {
        // We cannot identify any camera with a given value.
        return CAMERA_NODEV;
    }

    // During a construction, CameraDevice will obtain a handle of a target
    // camera device from the platform camera service.
    std::shared_ptr<CameraDevice> h = std::make_shared<CameraDevice>(id);
    if (!h) {
        // We fail to open a camera device.
        return CAMERA_EACCESS;
    }

    *out = h;
    return CAMERA_OK;
}

// Close a camera device associated with a given string identifier. This method
// is assumed to be always successful.
void CameraManager::close(std::string id) {
    if (!mCameraList.contains(id)) {
        // We ignore calls with unknown identifiers.
        return;
    }

    // mCameraList.remove() returns an object removed from the list.
    std::shared_ptr<CameraDevice> device = mCameraList.remove(id);

    // Ensure a device stops streaming.
    device->stop();
}

// Start a data stream that attributes are matching to given configuration
// best.
// If a selected configuration is not given (null), a data stream will be
// initiated in its default configuration and return.
CameraError CameraDevice::start(
        std::shared_ptr<CameraStreamConfiguration>& configuration,
        std::shared_ptr<CameraStreamListener>& listener,
        std::shared_ptr<CameraStreamConfiguration>* effective) {
    if (!listener) {
        return CAMERA_EINVAL;
    }

    // selectStreamConfiguration examines this camera's stream configurations
    // and returns the one closest to the selected configuration.
    CameraStreamConfiguration config = selectStreamConfiguration(configuration);

    // mDevice refers to the camera handle for the platform camera service. We
    // may need to translate CameraStreamConfiguration for the platform service.
    mDevice->configure(
        configuration.mWidth, configuration.mHeight, configuration.mFormat);

    // Start a data stream with a callback object.
    if (!mDevice->startStream(mCallback)) {
        // We failed to start a data stream.
        return CAMERA_EIO;
    }

    return CAMERA_OK;
}

// Stop a data stream.
void CameraDevice::stop() {
    if (!mDevice) {
        // Nothing to do if we don't have a valid camera handle for the
        // platform camera service.
        return;
    }

    mDevice->stopStream();
}

// Get a camera descriptor.
CameraError CameraDevice::getDescriptor(std::shared_ptr<CameraDescriptor>* desc) {
    if (!mDescriptor) {
        return CAMERA_ENODATA;
    }

    *desc = *mDescriptor;
    return CAMERA_OK;
}

// Return a consumed buffer to the camera device. A client of active stream
// must return a frame buffer explicitly by calling this method.
void CameraDevice::doneWithFrame(std::shared_ptr<FrameBuffer>& buffer) {
    if (!mBufferRecords.contains(buffer.getId())) {
        // Ignore a call with unknown frame buffer.
        return;
    }

    // Simply remove from the record.
    (void)mBufferRecords.remove(buffer.getId());
}

// This method handles gear-shift events.
void Application::handleGearShift(GearSelection selection) {
    switch (selection) {
        case GEAR_SELECTION_REVERSE:
            // Upon the reverse gear selection, we are going to start a video
            // stream and show its preview on the instrument cluster display.
            (void)startStream(mCameraInputBlock);

            // FIXME: Exact method to control the camera preview window on the
            // instrument display is to be determined.
            show(mRearVisibilityWindow);
            break;

        default:
            // Upon all other gear selection, we are going to stop a video
            // stream (if it's running) and hide the preview.
            stopStream(mCameraInputBlock);

            // FIXME: Exact method to control the camera preview window on the
            // instrument display is to be determined.
            hide(mRearVisibilityWindow);
            break;
    }
}

bool Application::startStream(std::shared_ptr<CameraInputBlock> handle) {
    return handle->start(std::bind(&Application::handleStreamCallback, this);
}

void Application::stopStream(std::shared_ptr<CameraInputBlock> handle) {
    handle->stop();
}

// This method handles a stream callback.
void Application::handleStreamCallback(StreamEvent& event) {
    switch (event.getType()) {
        case StreamEventType::kNewFrameBuffer:
            // Handle a new frame buffer. We may just enqueue it for the
            // future or forward to CameraInputBlock client.
            break;

        case StreamEventType::kStreamStopped:
            // Handle as an incident if this event is not expected.
            break;

        // More cases to be added.
    }
}

void Application::handleNewFrameBuffer(StreamEvent& event) {
    // Enqueue a new frame buffer for the further processing. A buffer
    // must be returned explicitly by calling
    // CameraDevice.doneWithFrame(FrameBuffer&) method.
}

void Application::handleStreamEvent(StreamEvent& event) {
    // Handle a received stream event except a new frame buffer's
    // arrival; e.g. a video stream is terminated unexpectedly.
}

Leistung

Die Sicht nach hinten entspricht diesen behördlichen Vorschriften.

Wert Verordnung
Antwortzeit CFR 571.111 S5.5.3
Framerate UNECE R46 6.2.2.3.4
Zeitpunkt der Bildgenerierung UNECE R46 6.2.2.3.4.2
Systemlatenz UNECE R46 6.2.2.3.4.3

Datenschutz

Datenschutz:

  • Für die API ist es nicht erforderlich, dass Implementierungen personenbezogene Daten (PII) erfassen, protokollieren oder speichern. Da erfasste Bilddaten oder zugehörige Metadaten jedoch personenidentifizierbare Informationen enthalten können, muss die App, die die API verwendet, die ausdrückliche Einwilligung des Nutzers einholen.

  • Nutzer können keine Kameras steuern, um eine Vorschau auf dem Kombiinstrument anzuzeigen, da die Kameras sicherheitskritische Funktionen haben. OEMs holen die Nutzereinwilligung während der Einrichtung oder vom Fahrer ein.

  • Diese API unterstützt keine Hintergrundkamera-Clients. Daher fällt der Datenschutzindikator, der Nutzer darüber informiert, dass ein Kameragerät Daten erfasst, nicht in den Anwendungsbereich.