Bei der Auslegung von Rückmeldungen für kapazitive Bedienelemente sollten vier Ereignisse unterschieden werden: Eine Berührung wurde erkannt, ein Befehl wurde angenommen, eine Aktion wurde abgeschlossen oder ein Fehler beziehungsweise eine Warnung ist aufgetreten. Weisen Sie jedem Signal eine eindeutige Bedeutung zu und lassen Sie das Signal von der Komponente freigeben, die weiß, dass das Ereignis eingetreten ist. Ein Signalton, ein beleuchtetes Symbol oder eine Vibration darf niemals allein deshalb eine erfolgreiche Maschinenfunktion suggerieren, weil ein Finger erkannt wurde.
Dieser Leitfaden konzentriert sich auf kapazitive Tasten und Tastenfelder mit fest zugewiesenen Funktionen. Die Koordinatengenauigkeit von Touchscreens, die Koordinatenzuordnung an den Rändern und die Multitouch-Validierung sind eigenständige Aufgaben. Nehmen Sie bei der Spezifikation kundenspezifischer kapazitiver Bedienfelder neben dem Tastenlayout und der elektrischen Schnittstelle auch die Zustandszuordnung für die Rückmeldungen auf.
- Trennen Sie die Eingabeerkennung vom Befehlsabschluss
- Wählen Sie eine visuelle, akustische oder haptische Bestätigung
- Visuelle Bestätigung
- Akustische Bestätigung
- Haptische Bestätigung
- Berücksichtigen Sie Geräusche, Handschuhe und die Aufmerksamkeit des Bedieners
- Weisen Sie Treibern, Firmware und Host klare Verantwortlichkeiten zu
- Validieren Sie Bedeutung und zeitliches Verhalten der Rückmeldungen
- Messen Sie die Ereigniskette
- Definieren Sie Prioritäten und Wiederherstellung
- Prüfen Sie die Interpretation durch den Bediener
- Häufig gestellte Fragen
- Sollte das Bedienfeld einen Signalton ausgeben, bevor der Host antwortet?
- Kann eine einzelne LED sowohl eine Berührung als auch den Maschinenzustand anzeigen?
- Kann ein Vibrationsimpuls bestätigen, dass ein Motor gestartet ist?
- Sollte jede erkannte Berührung eine Rückmeldung auslösen?
- Was sollte geschehen, wenn Benutzer die Tastentöne deaktivieren?
- Kann ein einzelner Aktor erkennen lassen, welche Taste berührt wurde?
- Ist das Rückmeldesystem mit dem Hinzufügen eines Haptiktreibers vollständig?
- Erstellen Sie für die RFQ einen Plan für Rückmeldungen an den Bediener
Trennen Sie die Eingabeerkennung vom Befehlsabschluss
Behandeln Sie Erkennung, Annahme, Abschluss und Fehler als getrennte Ereignisse, selbst wenn sie im normalen Betrieb gleichzeitig zu erfolgen scheinen. Ein Touch-Controller kann eine Eingabe melden; die für den Befehl verantwortliche Anwendung muss entscheiden, ob er zulässig ist und ob das beabsichtigte Ergebnis eingetreten ist.
Die folgende Ereigniszuordnung dient als Beispiel und schreibt keinen Farb- oder Toncode vor.
| Ereignis | Bedeutung der Rückmeldung | Verantwortung von Treibern und Firmware | Für den Bediener sichtbarer Zustand |
|---|---|---|---|
| Berührung erkannt | Ein qualifiziertes Tastenereignis ist aufgetreten; die Gültigkeit des Befehls steht noch nicht fest | Die Touch-Firmware qualifiziert das Ereignis; die lokale Schnittstellen-Firmware kann über den jeweiligen Treiber ein vereinbartes LED-, Ton- oder Haptiksignal auslösen | Kurze Reaktion am Berührungsziel; Entscheidung des Hosts steht aus |
| Befehl angenommen | Die Anwendung hat die Anforderung freigegeben; die Ausführung kann noch ausstehen | Die Host-Anwendung gibt die Annahme frei; die Schnittstellen-Firmware steuert die entsprechenden Treiber | Angenommen, in der Warteschlange oder in Ausführung; diese Zustände werden bei Bedarf unterschieden |
| Aktion abgeschlossen | Das festgelegte Ergebnis wurde bestätigt | Die Host- beziehungsweise Prozesslogik verifiziert das Ergebnis und veranlasst dessen Anzeige | Abgeschlossen oder der verifizierte resultierende Anlagenzustand |
| Fehler oder Warnung | Eine Anforderung wurde abgelehnt, die Ausführung ist fehlgeschlagen oder ein Zustand erfordert Aufmerksamkeit | Das Subsystem, das den Zustand erkennt, meldet ihn; die Host-Logik weist ihm Bedeutung und Priorität zu; die Schnittstellen-Firmware stellt ihn dar | Abgelehnt, fehlgeschlagen, nicht verfügbar oder Warnung mit einer handlungsleitenden Erklärung |
Kennzeichnen Sie nicht automatisch jede Warnung als fehlgeschlagene Aktion. Halten Sie fest, ob der Vorgang fortgesetzt, angehalten oder abgelehnt wird.
Bei einem beispielhaften Startbefehl kann eine Hervorhebung des Berührungsziels die Berührung bestätigen. Nach der Annahme durch den Host kann eine Betriebsanzeige folgen, nach dem verifizierten Prozessabschluss eine Abschlussanzeige. Eine Empfangsbestätigung auf Transportebene belegt den Empfang einer Nachricht, nicht deren Annahme durch die Anwendung. Ebenso beweist das Bestromen eines Ausgangs nicht, dass ein Mechanismus seine Zielposition erreicht hat.
Trennen Sie die Anzeigen für „bereit“, „deaktiviert“ und „beschäftigt“ von der Berührungsbestätigung. Legen Sie für jeden Zustand fest, was der Bediener als Nächstes tun soll, insbesondere wenn eine weitere Berührung Unklarheit erzeugen würde.
Wählen Sie eine visuelle, akustische oder haptische Bestätigung
Wählen Sie Rückmeldungen danach aus, welche Informationen sie vermitteln müssen, nicht nach der Anzahl verfügbarer Effekte. Verwenden Sie kurzzeitige Signale für einzelne Ereignisse und dauerhafte Anzeigen für Zustände, die der Bediener möglicherweise später prüfen muss.
Visuelle Bestätigung
Definieren Sie für die visuelle Bestätigung einer Touch-Taste das beleuchtete Berührungsziel, die Zustandsbeschriftung, die Anzeigedauer und die Bedingung zum Aufheben der Anzeige. Eine Hintergrundbeleuchtung, die lediglich beim Auffinden einer Taste hilft, darf nicht zugleich suggerieren, dass deren Befehl angenommen wurde.
Kombinieren Sie Farbe mit einem erkennbaren Symbol, einer Beschriftung oder einem anderen visuellen Unterscheidungsmerkmal. Die W3C-Erläuterungen zur Verwendung von Farbe beschreiben dieses Prinzip für Webinhalte. Die Übertragung auf Geräteanzeigen ist eine gestalterische Anpassung, keine Aussage zur Konformität des Geräts. Vergleichen Sie Prototypen unter dem vorgesehenen Betrachtungswinkel, bei der vorgesehenen Umgebungsbeleuchtung und mit der zu erwartenden Verdeckung durch Finger. Dokumentieren Sie, ob Bediener ausstehende Vorgänge, abgeschlossene Vorgänge und Fehlerzustände unterscheiden können, ohne deren Bedeutung allein aus der Farbe erraten zu müssen.
Akustische Bestätigung
Legen Sie für akustische Rückmeldungen eines kapazitiven Tastenfelds fest, welches Ereignis den Ton auslöst, sowie dessen Muster, Wiederholung, Lautstärkeregelung und Stummschaltverhalten. Vergleichen Sie ihn am Arbeitsplatz des Bedieners mit anderen Geräuschen der Anlage und berücksichtigen Sie dabei den vorgeschriebenen Gehörschutz. Erhöhen Sie nicht einfach die Lautstärke, bis eine Vorführung auf dem Prüfstand überzeugend erscheint.
Verwenden Sie eine dauerhaft sichtbare Erklärung, wenn ein kurzer Ton den Grund für eine Ablehnung nicht vermitteln kann. Dokumentieren Sie, ob sich gewöhnliche Bestätigungstöne stummschalten lassen und welche separat definierten Alarmanforderungen davon unberührt bleiben.
Haptische Bestätigung
Kapazitive Erfassung erzeugt selbst keine Vibration. Vibrotaktile Rückmeldung benötigt einen Aktor, kompatible Ansteuerelektronik, Versorgung, mechanische Kopplung und Auslöseregeln. DRV2605L ist ein Treiberbeispiel für Motoren mit exzentrisch rotierender Masse und lineare Resonanzaktoren; DRV2667 nutzt eine andere Architektur für Piezoaktoren. Diese Bauteilbeispiele sind weder austauschbare Lösungen noch ein Nachweis für eine gelieferte Bedienfeldkonfiguration.
Bewerten Sie die kapazitive Haptikrückmeldung im montierten Gehäuse. Spezifizieren Sie Aktorposition und Befestigung, Wellenform, Kontaktbereich und zulässige Vibrationsgeräusche. Kontrolliertes Stoppen unterstützt einen klar abgegrenzten Klick. Vergleichen Sie aufeinanderfolgende Effekte, statt nur einen einzelnen Impuls freizugeben.
Berücksichtigen Sie Geräusche, Handschuhe und die Aufmerksamkeit des Bedieners
Wählen Sie eine Kombination, die auch dann verständlich bleibt, wenn ein Kanal nicht verfügbar ist oder seine Signale nicht wahrgenommen werden. Die folgenden Kombinationen sind beispielhafte Ausgangspunkte für Prototypvergleiche, keine allgemein gültigen Vorgaben.
| Betriebsbedingung | Zu bewertende Kombination | Wesentliche Vergleichs- und Dokumentationspunkte |
|---|---|---|
| Der Bediener beobachtet das Bedienfeld in einer ruhigen Umgebung | Lokale visuelle Bestätigung mit optionalem dezentem Ton | Zustandserkennung, Verdeckung durch Finger und unnötig wiederholte Töne |
| Maschinenlärm oder Gehörschutz | Dauerhafte visuelle Zustandsanzeige; optionale Haptik während des Kontakts | Erkennung ohne verfügbaren Tonkanal und bei laufender Anlage |
| Die Aufmerksamkeit gilt hauptsächlich dem Werkstück | Kurzes akustisches oder haptisches Signal plus dauerhafte Ergebnisanzeige | Ob das Signal wahrgenommen wird und der Endzustand später überprüft werden kann |
| Freigegebene Handschuhe sind vorgeschrieben | Visuelle Bestätigung; akustische Signale und Haptik im eingebauten Zustand vergleichen | Berührungserkennung und Wahrnehmung der Rückmeldung als getrennte Ergebnisse für jede Handschuhbedingung |
| Häufiges Verstellen oder wiederholte Eingaben | Zurückhaltende Ereignissignale plus aktualisierte Wert- beziehungsweise Zustandsanzeige | Überlappende Signale, nicht erfasste Einstellschritte, doppelte Befehle und Verärgerung des Bedieners |
| Maschinenvibrationen oder zeitweiliger Handkontakt | Visuelle oder akustische Zustandsinformationen; Haptik erst nach Bewertung | Verwechslung mit Hintergrundvibrationen und Unterbrechung des taktilen Kontaktpfads |
Ein erfolgreicher Test der Berührungserkennung mit Handschuhen belegt nicht, dass derselbe Benutzer einen Aktor deutlich spüren kann. Umgekehrt kann eine stärkere Vibration eine nicht erkannte Berührung nicht ausgleichen. Dokumentieren Sie die Spezifikation, Passform und den Zustand der Handschuhe, die Körperhaltung, die Kontaktstelle und das zugehörige Erkennungsergebnis.
Verlassen Sie sich bei Aktionen, die erst abgeschlossen werden, nachdem die Hand das Bedienfeld verlassen hat, nicht allein auf dessen Vibration, um den Abschluss mitzuteilen. Beziehen Sie die tatsächliche Aufgabendauer und die Bewegungen des Bedieners in die Bewertung ein.
Weisen Sie Treibern, Firmware und Host klare Verantwortlichkeiten zu
Benennen Sie sowohl einen Verantwortlichen für das Ereignis als auch einen für die Ausgabe. Ein Treiber kann Licht, Ton oder Bewegung erzeugen, ohne zu wissen, ob ein Befehl gültig ist. Die Projektspezifikation muss diese Verantwortlichkeiten ausdrücklich miteinander verknüpfen.
Die Verantwortlichen für Abdeckung und Sensor definieren die grafische Kennzeichnung der Berührungsziele, die Sichtbarkeit der Anzeigen, die Sensorgeometrie und die Kontaktfläche im eingebauten Zustand. Bei Haptik legt der mechanisch Verantwortliche zusätzlich die Aktoraufnahme und den vorgesehenen Übertragungsweg der Vibration fest. Dokumentieren Sie die Revisionsstände von Zeichnungen und Baugruppe.
Die Verantwortlichen für Touch-Controller und Firmware definieren qualifizierte Betätigungs- und Loslassereignisse, das Verhalten beim Gedrückthalten, die Wiederholfunktion, die Filterung und den Diagnosezugriff. Legen Sie fest, ob ein Befehl beim Betätigen, beim Loslassen oder nach Abschluss des Gedrückthaltens ausgelöst wird. Eine Fortschrittsanzeige für das Gedrückthalten darf nicht wie eine Befehlsannahme wirken.
Die Verantwortlichen für Ausgangselektronik und Anzeige definieren die Treiber für LED, Signalgeber und Aktoren, den Stromversorgungsbedarf, die Ausgangszustände beim Start und, soweit verfügbar, die Fehlerdiagnose. Die Anzeigehardware stellt Informationen dar; die Schnittstellen-Firmware ordnet Ereignisse aus den jeweils maßgeblichen Quellen visuellen Zuständen, Tönen und Wellenformen zu. Benennen Sie den Verantwortlichen für diese Zuordnung und deren Revisionsstand.
Die Verantwortlichen für Host und Anwendung definieren Berechtigungen, den Umgang mit dem Beschäftigt-Zustand, die Befehlsannahme, den Abschlussnachweis, den Abbruch, Zeitüberschreitungen und die Wiederherstellung des Betriebs. Wenn Nachrichten über einen Bus übertragen werden, definieren Sie Befehlskennungen und den Umgang mit veralteten Nachrichten, damit eine verspätete Abschlussmeldung nicht als Bestätigung eines neueren Befehls erscheinen kann.
Bei einer integrierten Beschaffung sollte der Umfang der HMI-Montage die enthaltenen physischen Komponenten und deren Schnittstellen ausweisen. Spezifizieren Sie Controllerprogrammierung, Host-Software, Aktorauswahl und Systemvalidierung gesondert, statt „Montage“ automatisch mit der Verantwortung für diese Aufgaben gleichzusetzen.
Prüfen Sie die Erfassung auch während des Betriebs der Rückmeldeausgänge. LED-Ansteuerzustände können die Kapazität verändern und Fehlerkennungen verursachen. Wenden Sie die Hinweise zum ausgewählten Controller an und betreiben Sie anschließend Beleuchtung, Ton und Haptik gemeinsam im eingebauten System. Nutzen Sie für die umfassendere Prüfung des Schichtaufbaus den Leitfaden zur Auslegung kapazitiver Bedienfelder.
Validieren Sie Bedeutung und zeitliches Verhalten der Rückmeldungen
Validieren Sie, was Bediener verstehen und wann die physische Ausgabe erfolgt, nicht nur, ob die Firmware einen Wiedergabebefehl ausgegeben hat. Legen Sie vor dem Test projektspezifische Abnahmekriterien fest. Eine Angabe zur Anlaufzeit eines Treibers entspricht nicht der vollständigen Verzögerung zwischen Berührung und Rückmeldung.
Messen Sie die Ereigniskette
Erfassen Sie eine vereinbarte Referenz für die physische Eingabe, das qualifizierte Tastenereignis, die Annahme durch den Host, den verifizierten Abschluss und den tatsächlichen Beginn jeder zugehörigen Ausgabe. Verwenden Sie eine gemeinsame Zeitbasis oder dokumentieren Sie den Zeitabgleich der Uhren. Korrelieren Sie elektrische Protokolle je nach Bedarf mit einem Fotodetektor für Licht, einem Mikrofon für Ton oder einem Beschleunigungssensor für Vibration. Dokumentieren Sie die Position der Messgeräte und die Schwellen zur Ereigniserkennung.
Verwenden Sie die folgende beispielhafte Protokollvorlage. Die leeren Ergebnisfelder sind für Messungen an der tatsächlichen Baugruppe vorgesehen.
| Prüfung | Zu erfassendes Zeitverhalten oder Verhalten | Abnahmegrundlage | Tatsächliches Ergebnis |
|---|---|---|---|
| Erste Reaktion | Von der Eingangsreferenz bis zum qualifizierten Ereignis und zum Beginn des physischen Signals | Vereinbarte Reaktionsgrenze und korrekte Bedeutung des lokalen Signals | |
| Annahme | Von der Annahme durch die Anwendung bis zum Beginn des zugehörigen Signals | Kein Annahmesignal vor der Freigabe; korrekte Zuordnung zum Befehl | |
| Abschluss | Vom verifizierten Ergebnis bis zur dauerhaften Ergebnisanzeige | Festgelegtes Ergebnis verifiziert; keine Behauptung einer erfolgreichen physischen Ausführung allein aufgrund eines Zeitgebers | |
| Wiederholte Eingabe | Ereignisanzahl, Anzahl angenommener Befehle sowie Beginn und Ende der Signale | Vereinbarte Wiederholregeln; unterscheidbare Effekte | |
| Ablehnung oder Kommunikationsverlust | Erkennung des Zustands, Änderung der Anzeige und Dauer des ausstehenden Zustands | Definierte Zeitüberschreitung; keine falsche Erfolgsmeldung und keine unbegründete Aufforderung zur Wiederholung |
Wiederholen Sie die Prüfung unter den relevanten Bedingungen für Start, Ruhemodus und Aufwachen, Host-Auslastung, Stromversorgung und gleichzeitige Ausgaben. Dokumentieren Sie beobachtete Spannweiten und Ausnahmen statt nur eines Mittelwerts oder der schnellsten Vorführung.
Definieren Sie Prioritäten und Wiederherstellung
Geben Sie bei gewöhnlichen Betriebsrückmeldungen Fehlern und Erklärungen abgelehnter Befehle Vorrang vor normalen Bestätigungen. Legen Sie fest, welche Anzeigen bestehen bleiben, welche Effekte unterbrochen werden dürfen und welche nicht mehr relevant sind. Spielen Sie keine Berührungsbestätigungen aus der Warteschlange ab, wenn sie den aktuellen Zustand nicht mehr beschreiben.
Prüfen Sie das Design mit getrenntem Host, verzögerten oder doppelten Nachrichten, schnellen Berührungen, einer gehaltenen Taste, einem Reset während der Ausführung und einem nicht verfügbaren Ausgabekanal. Entscheiden Sie, ob zusätzliche Befehle im Beschäftigt-Zustand ignoriert, abgelehnt oder in eine Warteschlange gestellt werden. Eine Zeitüberschreitung kann bedeuten, dass das Ergebnis unbekannt ist, nicht, dass nichts geschehen ist. Verlangen Sie daher einen Zustandsabgleich, bevor Sie eine Wiederholung empfehlen.
Gewöhnliche Rückmeldungen ersetzen keine Sicherheitsfunktion. Behandeln Sie sicherheitsbezogene Steuerungen und das Alarmverhalten im dafür vorgesehenen Risiko- und Konformitätsprozess der Anlage.
Prüfen Sie die Interpretation durch den Bediener
Bitten Sie repräsentative Benutzer zu erklären, was jedes Signal bedeutet und was sie als Nächstes tun würden. Dokumentieren Sie Unklarheiten, wiederholte Berührungen, übersehene Warnungen und falsche Annahmen eines Abschlusses. Kombinieren Sie ein autorisiertes Video des Prototypbetriebs mit Ereignisprotokollen; ein Video allein belegt keine präzisen Zeitabläufe. Wiederholen Sie betroffene Prüfungen nach Änderungen an Firmware, Mustern, Aktorbefestigung oder Abdeckungsbaugruppe.
Häufig gestellte Fragen
Klären Sie diese Umsetzungsfragen, bevor Sie die Rückmeldespezifikation freigeben.
Sollte das Bedienfeld einen Signalton ausgeben, bevor der Host antwortet?
Nur wenn der Signalton ausdrücklich als lokale Berührungserkennung definiert ist. Er darf nicht wie eine Befehlsannahme oder ein Befehlsabschluss klingen. Ist diese Unterscheidung für Benutzer nicht eindeutig, verwenden Sie eine neutrale lokale visuelle Reaktion und reservieren Sie den zustimmenden Ton für die Annahme durch den Host.
Kann eine einzelne LED sowohl eine Berührung als auch den Maschinenzustand anzeigen?
Ja, sofern ihre Zustände unterscheidbar bleiben und die Prioritätsregeln ausdrücklich festgelegt sind. Definieren Sie, wie eine kurze Berührungsanzeige mit dauerhaften Anzeigen für Betrieb, Abschluss, Deaktivierung und Fehler zusammenwirkt. Testen Sie schnelle Berührungen, während jeweils einer dieser dauerhaften Zustände aktiv ist.
Kann ein Vibrationsimpuls bestätigen, dass ein Motor gestartet ist?
Nur wenn der Impuls durch das Ereignis freigegeben wird, das als verifizierter Motorbetrieb definiert ist. Ein vom Berührungssensor ausgelöster Impuls bestätigt die Eingabe, nicht die Motorbewegung. Spezifizieren Sie den erforderlichen Prozessnachweis, statt einen Ausgangsbefehl mit einer erfolgreichen physischen Ausführung gleichzusetzen.
Sollte jede erkannte Berührung eine Rückmeldung auslösen?
Nicht unbedingt. Definieren Sie das Verhalten bei deaktivierten Tasten, einer Reinigungssperre, ungültigen Haltevorgängen und abgelehnten Eingaben. Eine qualifizierte Berührung kann eine neutrale Reaktion oder eine Erklärung auslösen. Sie sollte jedoch nicht dasselbe zustimmende Signal wie ein angenommener Befehl erzeugen, wenn noch keine Annahme erfolgt ist.
Was sollte geschehen, wenn Benutzer die Tastentöne deaktivieren?
Erhalten Sie einen anderen verständlichen Bestätigungskanal und dauerhafte Ergebnisinformationen aufrecht. Behandeln Sie gewöhnliche Tastentöne getrennt von Alarmanforderungen. Prüfen Sie, ob die Stummschaltung nach einem Neustart erhalten bleibt, und stellen Sie sicher, dass die angezeigte Einstellung dem tatsächlichen Verhalten entspricht.
Kann ein einzelner Aktor erkennen lassen, welche Taste berührt wurde?
Setzen Sie dies nicht voraus. Prüfen Sie, ob Bediener die betreffende Taste anhand der Vibrationsantwort im eingebauten Zustand unterscheiden können. Bleibt die Tastenidentität unklar, stellen Sie eine lokale visuelle Anzeige oder eine andere eindeutige Kennzeichnung bereit, statt eine räumlich lokalisierte Haptik zu behaupten.
Ist das Rückmeldesystem mit dem Hinzufügen eines Haptiktreibers vollständig?
Nein. Das Design benötigt weiterhin einen kompatiblen Aktor, eine Befestigung, Stromversorgung, Wellenformkonfiguration, Ereigniszuordnung, Host-Integration und eine Validierung im eingebauten Zustand. Nehmen Sie diese Punkte und ihre Verantwortlichen in den Beschaffungsumfang auf. Ein Treiber oder ein physisches Bedienfeld allein definiert noch kein vollständiges System.
Erstellen Sie für die RFQ einen Plan für Rückmeldungen an den Bediener
Reichen Sie die Ereigniszuordnung zusammen mit der Bedienfeldspezifikation ein, damit das Angebot zwischen physischer Hardware und den Verantwortlichkeiten für Elektronik und Software unterscheiden kann.
Über Meinen Plan für Rückmeldungen an den Bediener prüfen können Sie das Tastenlayout, Zeichnungen von Abdeckung und Gehäuse, Rückmeldemuster, den Controller und die Host-Schnittstelle, vorgeschlagene Treiber oder Aktoren, Betriebsbedingungen, Prototypen- und Serienmengen sowie Abnahmekriterien übermitteln. Kennzeichnen Sie vom Käufer bereitgestellte Komponenten und die gewünschten Integrationsgrenzen, insbesondere für Akustik und Haptik.
Bereit für Ihr Projekt?
Beschreiben Sie Ihre Anforderungen an Folienschalter, Tastaturen oder Grafikfolien. Unser Engineering-Team prüft Ihre Spezifikationen und erstellt ein detailliertes Angebot.
