Home
Mikrocontroller
Keine Kompromisse bei Echtzeit-Traces
26.05.2008 | Autor: Alexander Weiss und Christian Hochberger*
Trace-Daten sind für viele Aufgaben wie formale Tests, Fehlererkennung oder Systemoptimierung wichtig. Ein neuer Ansatz ermöglicht es nun, aus Mikrocontrollern einen vollständigen Trace wie von einem Bond-Out-Chip zu gewinnen, gleichzeitig aber mit CPU-Geschwindigkeiten zu arbeiten, wie sie bisher nur bei Embedded-Trace-Lösungen möglich waren.
 | |
|
Einschränkungen traditioneller Trace-Methoden
Um Trace-Daten zu gewinnen wurde traditionell ein spezieller Bond-Out-Chip verwendet, bei dem der interne Bus von außen zugänglich war. Durch „Mitlauschen“ an diesem Bus konnte ein vollständiger Satz von Trace-Daten gewonnen werden. Neben den sehr hohen Kosten hat dieses Konzept den Nachteil, dass es aus physikalischen Gründen nur bis zu einer Taktfrequenz von ca. 50 MHz einsetzbar ist.
Für schnellere CPUs kommt deshalb ein zweiter Ansatz in Frage, der als Embedded Trace bezeichnet wird. Hier wird auf dem Mikrocontroller eine Einheit zur Erfassung von Trace-Daten implementiert, welche die gewonnen Informationen zwischenspeichert, komprimiert und über eine Schnittstelle nach außen gibt. Solch eine Embedded-Trace-Lösung ist beispielsweise das Nexus Interface oder ARMs ETM-Schnittstelle. Diese Trace-Einheit benötigt Chipfläche, die im normalen Betrieb des Mikrocontrollers nicht produktiv verwendet wird und von daher auf das notwendigste Maß reduziert werden muss.
Dem Wunsch nach vollständigen Informationen über die Arbeit der CPU steht ein eingeschränkter Trace gegenüber, da es schlicht unwirtschaftlich ist, mehr Trace-Informationen verfügbar zu machen. Mit ausgefeilten und dementsprechend teuren Emulatoren wird versucht, aus den limitierten Ressourcen eines Mikrocontrollers möglichst umfassende Informationen zu gewinnen. Übrig bleibt aber immer ein Kompromiss zwischen der auf dem Mikrocontroller für diese Zwecke implementierten Funktion und den Anforderungen des für den Softwaretest verantwortlichen Ingenieurs.
Diese Situation verschärft sich, wenn Multicore-Mikrocontroller eingesetzt werden. Hier muss für jede CPU eine eigene Trace-Einheit implementiert werden oder aber man ist gezwungen, sich mit dem Trace einer einzelnen CPU zufrieden zu geben.
Einen Ausweg aus dieser Situation stellt die Verwendung spezieller Evaluierungs-Chips dar, die über eine umfassende Embedded-Trace-Funktion verfügen und in der Auflage von einigen hundert bis tausend Stück nur für Entwicklungszwecke gebaut werden. Neben den hohen Kosten für diese Chips kann der Hersteller nur selten eine vollständige Kompatibilität zu den später verwendeten Serien-Mikrocontrollern garantieren.
Emulation verbindet Vorteile aus Embedded-Trace- und Bond-Out-Chip-Ansätzen
Ein neuer und verblüffend einfacher Ansatz vereint die Vorteile der beiden traditionellen Techniken miteinander. Mit hidICE (hidden ICE) ist es möglich, einen vollständigen Trace wie von einem Bond-Out-Chip zu gewinnen, gleichzeitig aber mit CPU-Geschwindigkeiten zu arbeiten, wie sie bisher nur bei Embedded-Trace-Lösungen möglich waren. Der Grundgedanke besteht darin, dass die Trace-Daten nicht mehr vom zu untersuchenden Mikrocontroller direkt, sondern von einer parallel laufenden Emulation der CPU gewonnen werden. Diese zweite CPU befindet sich direkt im Emulator und muss funktionsidentisch zur CPU des Mikrocontrollers sein.Wenn der Programmspeicher beider CPUs den gleichen Code beinhaltet, führen die CPUs nach einem Reset auch die gleichen Instruktionen aus. Individuelle Änderungen des Programmlaufs entstehen erst durch das Lesen von Daten zur Laufzeit sowie durch den Einfluss auftretender Ereignisse (Interrupts).
Die Idee hinter hidICE ist nun, dass nur die zur Synchronisation beider Programmabläufe erforderlichen Daten vom Mikrocontroller zur emulierten CPU übertragen werden. Damit wird sicher gestellt, dass beide CPUs die gleichen äußeren Einflüsse erleben und dadurch den gleichen Programmablauf haben. Nun ist es ein leichtes, innerhalb des Emulators auf alle Trace-Informationen zuzugreifen. Neben den ausgeführten Instruktionen sowie von der CPU gelesenen und geschriebenen Daten stehen nun auch noch weitere Informationen wie DMA-Trace und CPU-Register-Trace (Stackpointer) zur Verfügung.Bei einer Embedded-Trace-Lösung werden mit sehr großem Aufwand die Programmsprünge sowie von der CPU gelesene und geschriebene Daten ausgegeben. Dabei wird viel Ingenieursarbeit darauf verwendet, diese Daten möglichst effizient zu übertragen und die Datenverluste bzw. die Beeinflussung des Systems durch notwendiges Anhalten der CPU gering zu halten. Die zur Synchronisation beider CPUs in einem hidICE-System erforderlichen Daten stellen nur einen Bruchteil der Datenmenge dar, die bei einer Embedded-Trace“-Lösung übertragen werden müssen.
Zur Synchronisation des Mikrocontrollers mit der Emulation müssen im Wesentlichen nur Informationen über einen aufgetretenen Interrupt, über temporäre Stopps des Busses und der CPU sowie die aus dem IO-Bereich (UART, CAN, ADC usw.) gelesenen Daten übertragen werden. Wenn diese Informationen synchron mit dem CPU-Takt übertragen werden ist es sehr einfach, den vollständigen Programmablauf in der emulierten CPU nachzubilden.
Die Emulation kann für langsamere Mikrocontroller in einem FPGA vorgenommen werden. Dies hat den Vorteile, dass der gleiche Emulator verschiedene Zielsysteme unterstützen kann, indem das FPGA jeweils entsprechend konfiguriert wird.
Für schnellere Mikrocontroller, für die die Geschwindigkeit eines FPGAs nicht mehr ausreicht, muss die Emulation in einem ASIC / ASSP implementiert werden. Im Unterschied zu Bond-out bzw. Evaluation-Chips reicht hier aber eine Implementierung für die Unterstützung aller Derivate mit der gleichen CPU.
Identischer Programmablauf von Emulation und MCU durch Integritätskontrolle
Ein wichtiger Punkt bei einer hidICE-Implementierung ist, dass der identische Programmablauf beider CPUs sichergestellt ist. Würde bei der Emulation ein Fehler auftreten, so liefen beide CPUs unweigerlich auseinander und der gewonnene Trace wäre nutzlos. Um solch einen Fehler erkennen zu können, werden im Mikrocontroller kontinuierlich Hashwerte über Daten und Instruktionen gebildet. Wird dieser Hashwert auch in der emulierten CPU berechnet, kann festgestellt werden, ob beide CPUs synchron laufen.
Mit dieser Methode (hidICE System Integrity Control) kann aber nicht nur die korrekte Arbeitweise der Emulation nachgewiesen werden, gleichzeitig werden nun auch sporadische Fehler erkannt, welche im Serien-Mikrocontroller auftreten. Diese können beispielsweise durch systematische Designfehler, instabile Speicherzellen, Probleme mit der Spannungsversorgung, zu enge Timings etc. verursacht werden und sind mit anderen Methoden nicht oder nur mit extrem großem Aufwand zu finden.
Mit der hidICE-Technologie kann der Zeitpunkt des Auftretens eines solchen Problems genau erkannt werden, obendrein steht noch ein Trace der Vorgeschichte des Fehlers zur Verfügung. Mit dieser Methode ist nun auch die umfassende Analyse von Mikrocontrollern möglich, die in Serienprodukten verbaut wurden und im Feld Auffälligkeiten zeigten, die eine interne Fehlfunktion vermuten lassen.
Erweiterter Debug-Support
Breakpoints können in beliebiger Anzahl im Emulator implementiert werden. Damit entfällt die aufwändige Logik für Breakpoints im Mikrocontroller. Da die Emulation aufgrund der erforderlichen Übertragungszeit der gelesenen Daten um eine definierte Anzahl von CPU-Zyklen verzögert ist, hält die CPU des Mikrocontrollers beim Auftreten einer gültigen Break-Bedingung im Emulator einige Taktzyklen verspätet an.
Für die meisten Breakpoints ist dies akzeptabel, zusätzlich können aber auch im Mikrocontroller wie bisher gewohnt Breakpoints implementiert werden, die dessen CPU ohne Verzögerung anhalten können. Es empfiehlt sich, emulatorseitige Breakpoints zur Abdeckung von Fehlerbedingungen zu verwenden, welche „eigentlich“ nie vorkommen sollten und die Breakpoints der Target-CPU für die direkte Programmkontrolle (Step, goto etc.) zu verwenden.
Erweiterte Trace-Informationen
Durch die CPU-Emulation innerhalb des Emulators kann sehr leicht auf Informationen zugegriffen werden, die mit traditionellen Technologien nicht oder nur sehr eingeschränkt verfügbar gemacht werden konnten.
DMA Trace : Durch die Notwendigkeit, dass bei einem DMA-Trace neben den transferierten Daten auch die Start- und Zieladressen des Transfers mit übertragen werden müssen, ist eine Implementierung mit dem „embedded trace“ Ansatz sehr aufwändig. Bei einer hidICE Implementierung stehen diese Informationen zur Verfügung.
CPU Register Trace: Auch ein Trace einzelner CPU-Register ist mit hidICE möglich. Damit kann beispielsweise in Echtzeit der Verlauf der Stackpointer analysiert werden.
Bus Trace: Durch die vollständige Beobachtbarkeit des emulierten Systems kann auch ein Trace aller Ereignisse auf dem Bussystem verfügbar gemacht werden. Damit lassen sich beispielsweise die Ursachen von Performanceeinbußen auf dem Bus analysieren und beseitigen.
Die beschriebenen Informationen stehen in einem hidICE basierten System kontinuierlich und in Echtzeit zur Verfügung. Ein (zeit-)aufwändiges Zurückrechnen und Rekonstruieren dieser Informationen, wie es bei „embedded trace“-Lösungen teilweise angeboten wird, ist nicht erforderlich.
Reduktion der Anzahl benötigter I/O-Pins
Ein wichtiges Bewertungskriterium für eine Trace-Technologie ist neben den benötigten On-Chip-Ressourcen auch die Anzahl der zur Ausgabe der Trace-Informationen benötigten Pins. An dieser Stelle kommt ein weiterer Vorteil der hidICE Technologie zur Geltung.Eigentlich geht aus Sicht der Applikation gar kein Pin verloren, wenn Trace-Daten aufgezeichnet werden. Dies ist mit zwei Einschränkungen tatsächlich möglich: Die zur Synchronisation erforderlichen Pins müssen im Nomalbetrieb Output-Pins sein und dazu noch recht langsam. Bei den meisten Designs lassen sich diese Bedingungen erfüllen, wenn beispielsweise ein Pin eine LED ansteuert oder ein Pulsgenerator-Ausgangssignal bereitstellt. Nun kann eine Port-Replacement-Technik angewandt werden, wie sie in Abbildung 3 erläutert ist.
Auch bei zahlreichen „embedded trace“ Ansätzen ist der Schalter S1 implementiert, d.h. es können Pins sowohl als I/O als auch zur Ausgabe von Trace-Daten verwendet werden. Der entscheidende Unterschied ist aber, dass die Verwendung der betreffenden Pins als I/O nicht gleichzeitig mit der Erfassung eines Traces geschehen kann.
Wird der Trace nicht nur zur Fehlersuche verwendet, sondern zur formalen Verifikation benötigt, sind diese I/O-Pins konsequenterweise nicht in der Applikation verwendbar. Anders bei hidICE – aus Sicht der Applikation sind immer alle Pins verfügbar, egal ob ein Trace aufgezeichnet wird oder nicht. Die einzige Limitation ist, dass der Pin mit einer definierten Verzögerung von einigen CPU-Taktzyklen geschaltet wird und nur als Ausgang arbeiten kann.
Entwicklung und Zertifizierung auf Serien-Mikrocontrollern
Initial wurde schon die Verwendung von Evaluation-Chips während der Entwicklungs- und Testphase diskutiert. Neben den sehr hohen Kosten besteht das Hauptproblem dieses Ansatzes darin, dass aufgrund unterschiedlicher Prozesstechnologien, einer unterschiedlichen Peripherieausstattung, zwischen-zeitlich getätigter Bugfixes etc. selten ein Hersteller die vollständige Kompatibilität von Evaluation-Chip und Serien-Mikrocontroller garantieren kann.
Diese eventuelle Inkompatibiliät führt nun zu der Situation, dass mit großem Aufwand Software auf einem System getestet wird, welches dann mit dem eigentlichen in der Serie eingesetzten System nicht unbedingt identisch ist. Dies kann bei nicht sicherheitsrelevanten Funktionen zu Ausfällen und damit schlimmstenfalls zu teuren Rückrufaktionen führen. Im sicherheitsrelevanten Bereich sollte diese Inkompatibiliät grundsätzlich nicht akzeptiert werden.
An dieser Stelle bietet ein hidICE basiertes System in Kombination mit der Systemintegritätskontrolle die Möglichkeit, Inbetriebnahme, Test und Zertifizierung auf dem tatsächlichen Serien-Mikrocontroller durchzuführen. Weiterhin entfallen die Kosten und eventuelle zeitliche Verzögerungen, die die Verwendung individueller Evaluationschips mit sich bringen.
Trace von Multicore-Mikrocontrollern
Das hidICE Prinzip lässt sich vergleichsweise einfach auch auf Multicore-MCUs anwenden. Mit deutlich weniger I/O-Pins als beispielsweise ein NEXUS Class 3 Interface und einem minimalen Bedarf an Chipfläche auf dem Mikrocontroller lässt sich ein vollständiger Trace von zwei CPUs (inkl. Daten- und Register-Trace) sowie der ausgeführten DMA-Transfers im Emulator zugänglich machen. Dabei führen n neue Busmaster (CPU oder DMA) nicht zu einer n-fachen Erhöhung der Anzahl der von hidICE im Mikrocontroller benötigten Ressourcen, vielmehr sind pro zusätzlicher CPU meist nur 2 oder 3 zusätzliche Pins erforderlich.
Implementierungen am Beispiel eines ARM Cortex M1 Demo-Systems
Da sich auf dem zu untersuchenden Mikrocontroller die Funktionalität des hidICE-Interfaces auf die Ermittlung des Hash-Wertes als auch auf das „Einsammeln“ der für die Synchronisation relevanten Informationen (im wesentlichen CPU-Clock, gelesene Daten, Interrupts, DMA-Requests sowie Bus- und Pipeline-Stop) beschränkt, ist der Aufwand für die Implementierung eines hidICE Interfaces erstaunlich klein. Es wurden verschiedene Demonstrationssysteme implementiert, eines davon soll hier näher vorgestellt werden.
Das System besteht aus zwei Actel M1-enabled ProASIC3 Boards (Bild 4). Die verwendete CPU ist ein ARM Cortex M1 [11][12] mit den folgenden Eigenschaften:32-Bit RISC Architecture (ARMv6-M)
32-Bit AHB-Lite Bus Interface
3-Stage Pipeline
32-Bit ALU
32-Bit Memory Addressing Range
Mittels der Actel CoreConsole IP Deployment Platform wurde ein Mikrocontroller entworfen, welcher aus dem genannten Cortex M1 Core besteht, der via eines AHB lite Busses [13] an ein Memory Interface (CoreMemCtrl) sowie an eine AHB-to-APB Bus Bridge (CoreAHB2APB) angeschlossen ist. An den APB Peripheriebus [14] ist eine GPIO Einheit (CoreGPIO), ein UART (CoreUARTapb) sowie ein Timer angeschlossen (Bild 4).Der Mikrocontroller wurde mit zwei Modulen erweitert, wovon eines (hidICE IP – Hash) rekursive Hash-Werte aus den folgenden Signalen des AHB-Busses berechnet:
HADDR (Adressen von Instruktionen und Daten)
HRDATA (gelesene Instruktionen und Daten)
Ein zweites Modul (hidICE IP – Sync TX) „sammelt“ folgende Daten ein:
CPU Clock (SYSCLK)
CPU Reset (NSYSRESET)
Timer Interrupt (IRQ)
vom APB Bus gelesene Daten (PRDATA)
die bereits berechneten Hash-Werte
Diese Daten werden komprimiert, so dass in diesem System nur 3 Pins benötigt werden, um sie zum Emulator zu übertragen.
Der Emulator besteht aus den gleichen Einheiten wie der Mikrocontroller, nur die Peripherie ist nicht vorhanden. Statt dessen werden die im Mikrocontroller vom APB Bus gelesenen Daten in die AHB-to-APB Bus Bridge eingespielt, so dass der AHB Bus im Emulator die gleichen Ergebnisse einer Leseoperation auf den APB Bus bekommt wie der Mikrocontroller. Ebenso werden CPU Clock, Reset und das Interrupt-Signal restauriert.Wie im Mikrocontroller, wird auch im Emulator ein Hash aus HADDR und HRDATA berechnet. Dieser Wert wird mit dem übertragenen Hash des Mikrocontrollers verglichen – sind die Werte identisch, kann davon ausgegangen werden dass beide Systeme synchron laufen und damit der im Emulator gewonnene Trace auch für den Mikrocontroller Gültigkeit besitzt. Der gewonnene Trace hat eine Breite von 217 Bit (Tabelle 1).
Zur Erfassung dieses Traces werden nur 3 Pins und 1182 Gates (Tabelle 3) im zu beobachtenden Mikrocontroller benötigt. Wenn man den Trace näher betrachtet, sieht man hier den gleichen Informationsgehalt, den ein im System angeschlossener Logikanalyzer liefern könnte, wenn er im State-Modus betrieben wird. Es ist damit möglich, die Arbeit des Busses taktgenau mitzuverfolgen und mit diesen Informationen eine solide Grundlage für Fehlersuche oder weitere Optimierungen zu haben.Erste Evaluierungen für den Einsatz in Serien-Mikrocontrollern
Für eine Reihe von Mikrocontrollerfamilien wurde eine mögliche Implementierung geprüft. Der Bedarf an Ressourcen ist im Vergleich zu traditionellen Technologien sehr gering, exemplarisch ist er für einige Mikrocontroller-Familien in Tabelle 4 dargestellt. Aktuelle werden mit mehreren Anbietern von Mikrocontrollern hidICE-Implementierungen evaluiert. Erste Mikrocontroller, die mit der hidICE Technologie ausgestattet sind, werden im Jahr 2009 erwartet.Tool-Unterstützung
Der Erfolg einer neuen Technologie hängt auch wesentlich von der Akzeptanz und Unterstützung dieser Technologie durch Drittanbieter ab. Bezüglich der hidICE Technologie haben bereits mehrere bedeutende Toolhersteller ihr Interesse zur Unterstützung hidICE basierter Systeme signalisiert. Um initial möglichst ohne größeren Zeitverlust eine derartige Unterstützung anbieten zu können, wird für erste Systeme eine Konvertierung der mittels hidICE gewonnenen Trace-Daten auf ein Nexus-kompatibles Format diskutiert.
Um die damit einhergehenden Verlust von Informationen zu vermeiden, andererseits aber auch die extreme Breite des Traces zu beherrschen, wird ein konfigurierbares Interface diskutiert, welches mittels eines Descriptor-Files die für die aktuelle Aufgabenstellung relevanten Daten auf eine 100-300 Bit breite Schnittstelle legt. Somit können beispielsweise für einen „Modified Condition/Decision Coverage“ Test der Instruktions-und Daten-Adressbus sowie der Datenbus der CPU auf dieses Interface gelegt werden, für eine Analyse des Stacks wären es der Instruktionsadressbus sowie die beiden CPU Register die den System- und den Userstack beinhalten.
hidICE vereint die Vorteile der etablierten Trace-Techniken, indem es die vollständigen Trace-Daten, die man von einem Bond-Out-Chip gewinnen kann, mit den hohen Taktfrequenzen einer „embedded trace“ Lösung kombiniert. Durch die sehr schlanke hidiCE-IP kann eine deutlich preiswertere Implementierung als bei einer „embedded trace“ Lösung erfolgen. Damit kann hidICE ohne größere Mehrkosten in Serien-Mikrocontrollern eingesetzt werden und erlaubt die Entwicklung und Zertifizierung von Anwendungssoftware unter realen Bedingungen auf der gleichen Hardware, wie sie später auch im Automobil eingesetzt wird.
*Alexander Weiss ist Geschäftsführer bei der Accemic GmbH & Co. KG in Flintsbach. Kontakt: aweiss@accemic.com. Prof. Dr.-Ing. Christian Hochberger ist Professor für Mikrorechner an der TechnischenUniversität Dresden, Fakultät Informatik, Institut für Technische Informatik. Email: christian.hochberger@inf.tu-dresden.de.
Social Networks:
Themenverwandte Beiträge
Emulator: Mehr Trace als Nexus erlaubt
04.05.2007 - Moderne MCUs werden immer komplexer, die Taktfrequenz steigt. Hier stoßen aktuelle Technologien zum Erhalt von Trace-Daten schnell an ihre Grenzen. Möglichst komplette Trace-Daten
weiter
Digital Signal Controller: Die Stärken eines Digital Signal Controller
Digital Signal Controller: Die Stärken eines Digital Signal Controller
12.09.2006 - Bestimmte Anwendungen erfordern Prozessoren, die gleichermaßen schnellen Echtzeitanforderungen als auch rechenintensiven Aufgaben im Bereich der digitalen Signalverarbeitung genügen müssen. Diese Applikationen sind oft auch noch preissensitiv und müssen hohen Sicherheitsanforderungen entsprechen. Was in solchen Fällen Digital Signal Controller von Mikrocontrollern und DSPs abhebt, welche typischen Anwendungen es gibt und wie eine moderne DSC-Familie aussehen kann, zeigt dieser Bericht.
weiter
Mikrocontroller: Innovasic mit eigener 32-Bit-MCU
Mikrocontroller: Innovasic mit eigener 32-Bit-MCU
22.09.2006 - Das eigentlich als Lieferant für Ersatz-ICs bekannte, Fab-lose US-Halbleiterunternehmen Innovasic Semiconductor stellt nun erstmals einen eigenentwickelten Mikrocontroller für industrielle
weiter
Lizenzierung urheberrechtlich geschützter Artikel
Nutzen Sie diesen Artikel ID 254965 oder andere Fachinformationen für Ihr Marketing. Wir bieten Ihnen die Nutzungsrechte für Ihre Website, Ihren Newsletter oder Ihre Kundenzeitschrift. Für alle Fragen wenden sie sich bitte an Frau Maurer unter Tel. 0931 / 418-2888 oder unseren Content-Dienstleister www.mycontentfactory.de .
Artikel versenden
Druckversion
Artikel als PDF
Artikel Bewertung
pls Programmierbare Logik & Systeme GmbH
Lauta, Deutschland
MSC Vertriebs GmbH
Stutensee, Deutschland
Debugging von Embedded Linux-Anwendungen auf ARM-Prozessoren
Embedded Linux als Betriebssystem für moderne ARM-Prozessoren? Keine schlechte Idee! Aber da Linux ein Multitasking-Betriebssystem ist, verkompliziert sich das Debuggen von Prozessen. Wirklich?
Embedded Linux als Betriebssystem für moderne ARM-Prozessoren? Keine schlechte Idee! Aber da Linux ein Multitasking-Betriebssystem ist, verkompliziert sich das Debuggen von Prozessen. Wirklich?
Multicore- und Multiprozessor-Debugging vereinfachen
Optimale Nutzung der JTAG Scan Chain zum Debuggen mit dem Workbench On-Chip-Debugging
Optimale Nutzung der JTAG Scan Chain zum Debuggen mit dem Workbench On-Chip-Debugging
Symmetric Multiprocessing einführen
Best Practices für Embedded-Entwickler für die Erkennung und Extraktion von Parallelismus in seriell designten Anwendungen und für die Softwareentwicklung.
Best Practices für Embedded-Entwickler für die Erkennung und Extraktion von Parallelismus in seriell designten Anwendungen und für die Softwareentwicklung.
Weniger Risiko in Embedded-Designs
Flexible 32-Bit-Mikrocontroller- Architektur für harte Echtzeitanwendungen
Flexible 32-Bit-Mikrocontroller- Architektur für harte Echtzeitanwendungen
Meine ELEKTRONIKPRAXIS
Benutzer
Passwort
Passwort
Copyright © 2010 Vogel Business Media
zum Login