 |
|
Überraschend anders
überraschend
effektiv
|
Timingsuite
Timinganalyse nach dem neusten Stand der Technik und gleichzeitig mit betriebsbewährten Methoden und Werkzeugen. T1 macht es möglich.
T1 ist im Automobilbereich das am häufigsten eingesetzte Timingwerkzeug. Seit vielen Jahren im Einsatz – in hunderten von Serienprojekten.
Mit der Zertifizierung der T1-TARGET-SW nach ISO 26262 ASIL‑D kann weltweit zum ersten Mal überhaupt auf Instrumentierung basierte zertifizierte Timingabsicherung und Timinganalyse betrieben werden. Im Fahrzeug. In der Serie. Die aufklappbaren Themenbalken unten geben viele Informationen zu T1. Und unter Success Stories lesen Sie, was unsere Kunden über ihre Erfahrung mit T1 berichten. 
T1 teilt sich auf die T1 Targetsoftware (T1-TARGET-SW), die auf dem Zielsystem läuft, und der T1 Hostsoftware (T1-HOST-SW), die auf dem PC läuft, auf.
Als Targetinterface kann CAN, FlexRay™, JTAG, oder Nexus dienen. Anders als bei anderen Lösungen, benötigt T1 nur sehr wenig Bandbreite für die Kommunikation. Nur so ist erklärbar, warum T1 gerade in Serienprojekten so erfolgreich eingesetzt wird. Dort ist Bandbreite typischerweise rar. Sind die Daten – zum Beispiel Scheduling Traces – an den PC übertragen, werden sie visualisiert und analysiert. Die Generierung von Reports und die Möglichkeit, alle T1 Funktionen auch über die Automatisierungsschnittstelle anzusprechen, erlauben die perfekte Integration in Testprozesse. Die T1-TARGET-SW leistet aber noch mehr als die reine Erfassung von Daten. In Echtzeit wird auf dem Zielsystem analysiert, ob zum Beispiel Deadlines verletzt wurden. Ist das der Fall, können optional Umgebungsinformationen abgespeichert werden, die dann eine detaillierte Analyse offline erlauben. Auch komplexe Ursachen für Laufzeitfehler lassen sich auf diese Weise aufdecken.
T1 setzt sich aus verschiedenen Komponenten, genannt T1 Plug-ins, zusammen.
T1.scope – Das Oszilloskop für Ihre SoftwareOb bei der Softwareentwicklung, der Integration oder bei der Verifikation: ohne die Visualisierung des realen Systems fehlt der Einblick in das, was tatsächlich auf dem Prozessor passiert.T1.scope ermöglicht diesen Einblick und versetzt Entwickler, Integratoren und Tester in die Lage, das Timing ihrer Embedded Software abzusichern. Die Anwendung ist denkbar einfach: der T1.scope Targetcode erfasst betriebssystemrelevante Ereignisse, wie Start und Ende von Tasks oder Interrupts und übermittelt diese an die T1.scope Hostsoftware. Dort werden die Ereignisse ähnlich wie bei einem Oszilloskop über eine Zeitachse dargestellt. Auch benutzerdefinierte Ereignisse können einbezogen werden. Zusätzlich zur grafischen Darstellung kommt die quantitative Auswertung, in deren Rahmen unter anderem die Nettolaufzeiten (core execution time) von Tasks, Interrupts, Runnables, ausgewählten Funktionen bis hin zu beliebigen Codeabschnitten berechnet werden. Die Reportgenerierung rundet das Spektrum der T1.scope Features ab. T1.cont – On-target Laufzeitanalyse und LaufzeitüberwachungAnders als bei T1.scope erfolgt bei T1.cont die quantitative Auswertung auf dem Target selbst. Lückenlos werden alle Instanzen aller Tasks und Interrupts einbezogen, sodass die Minimal- und Maximalwerte der betrachteten Timingparameter jedes Vorkommen zur Laufzeit berücksichtigen. Optionale Timing Constraints erlauben es, frühzeitig auf die Verletzung frei definierbarer Grenzen aufmerksam zu machen. So kann zum Beispiel eine Callback konfiguriert werden, die aufgerufen wird, sobald die Nettolaufzeit einer Task einen bestimmten Wert überschreitet. Werden zusätzlich zur Verwendung der Constraints noch die Laufzeitergebnisse in nichtflüchtigen Speichern wie NVRAM oder EEPROM abgelegt, erhält man eine Timingabsicherung, die in der Praxis der statischen Schedulinganalyse oder Schedulingsimulation überlegen ist. Bei diesen modellbasierten Ansätzen gehen Abweichungen des Modells von der Realität zu einem wesentlichen Teil "in die falsche Richtung", wiegen den Anwender dieser Methoden in einer falschen, nämlich nicht existenten Sicherheit.Wie T1.scope erlaubt auch T1.cont die Zusammenfassung der Ergebnisse in Form eines Reports. T1.flex – Flexible on-target LaufzeitmessungAls Erweiterung zu T1.scope und T1.cont bietet T1.flex die Möglichkeit, ohne zusätzliche Instrumentierung die Laufzeit von Funktionen und sogar beliebigen Codeabschnitten auszumessen. Die Auflösung bei der Auswahl des auszumessenden Codefragments ist ein Maschinenbefehl. Auch die Bestimmung der Zugriffshäufigkeit auf Code und Daten oder der T1 "Data Access Inspector" (siehe Screenshots auf dieser Seite) werden durch T1.flex ermöglicht. Um es auf den Punkt zu bringen: T1.flex erlaubt die Auswahl des auszumessenden Codes / der auszumessenden Daten zur Laufzeit, ohne dass die Anwendung instrumentiert, compiliert und neu geflasht werden muss. Das spart erheblich Zeit und Geld. Die auszumessenden Symbole werden einfach im Symbolbrowser ausgewählt, die interessanten Codepassagen im integrierten Quellcodebrowser einfach markiert.T1.delay – Injektion von NettolaufzeitMittels T1.delay lässt sich zur Laufzeit konfigurierbar zusätzliche Nettolast erzeugen. Zunächst wird definiert, an welcher Stelle im Code die Last entstehen soll. Zur Laufzeit kann dann auf die Mikrosekunde genau vorgegeben werden, wie groß die Verzögerung sein soll, also wie lange der injizierte Code laufen soll. Selbstredend sind mehrere Delays gleichzeitig möglich.Darüber hinaus lässt sich jedes Delay in regelmäßigen Abständen (z.B. alle zwei Sekunden) um einen zuvor definierten Wert vergrößern. Damit lässt sich ein System langsam und kontrolliert an seine (Timing-) Grenzen fahren. Ein idealer Ansatz, um empirisch den "Headroom" zu ermitteln, also festzustellen, wie viel "Luft" nach oben hin noch ist. T1.api – Timingverifikation auf RTOS- und CodeebeneT1.api bietet die vollständige Automatisierung von Laufzeitmessungen. Die Anbindung an die Testumgebung erfolgt mittels XML basierter Skripte, die entweder von einer .NET Schnittstelle oder der Kommandozeile angestoßen werden. Besonders effizient ist die Integration der Laufzeitverifikation in bestehende funktionale Tests, üblicherweise HIL Tests. Auf diesem Wege erhält man zusätzlich zu den funktionalen Tests die Absicherung der Laufzeit praktisch ohne zusätzlichen Testaufwand.T1.diff – Laufzeitmonitoring im ProjektverlaufIm Verlauf eines jeden Softwareprojektes gibt es verschiedene Meilensteine, Integrationsstufen, Softwarestände. T1.diff erlaubt den Vergleich mehrerer Softwarestände und liefert so wertvolle Informationen darüber, wie sich das Timing im Projekt entwickelt.Doch nicht nur das. T1.diff erlaubt auch die Angabe von Schwellwerten, bei deren Überschreitung Warnungen oder Fehler erzeugt werden. So lässt sich z.B. festlegen, dass bei einer Vergrößerung der Nettolaufzeit eines beliebigen Runnables um mehr als 10% eine Warnung, bei mehr als 15% ein Fehler ausgegeben wird. Kombiniert mit automatisierten Tests und T1.api lässt sich so sehr effizient und wirkungsvoll und ohne jeden manuellen Eingriff die Entwicklung des Timings im Projektverlauf überwachen. Konkretes Beispiel aus der Praxis gefällig? Immer mehr Projekte setzen auf modellbasierte Softwareentwicklung mit automatischer Codegenerierung. Bei allen Vorteilen, die dieser Ansatz mit sich bringt, birgt er auch einen großen Nachteil: der Ressourcenbedarf einer Software wird für den einzelnen Entwickler immer abstrakter. Wir konnten Situationen beobachten, bei denen eine vermeintlich kleine Änderung am Modell die Verzehnfachung des Laufzeitbedarfs mit sich brachte. Alles kein Problem - solange dies automatisiert z.B. mittels T1.diff/T1.api aufgespürt und transparent gemacht wird. T1.mod – On-line DatenzugriffeBei der Softwareentwicklung – und insbesondere bei der Low-level Softwareentwicklung – ergibt sich immer wieder der Bedarf, im laufenden Betrieb Variablen oder beliebige Speicherzellen auszulesen und zu beschreiben. Gegebenenfalls auch ohne den Prozessor anzuhalten, was meist die Arbeit mit einem Debugger mit sich bringt.T1.mod bietet diese Möglichkeit, ganz einfach und unkompliziert. Ist eine ELF Datei verfügbar, kann der Anwender mit Symbolnamen arbeiten. Doch auch über die direkte Adresseingabe wird der Speicherzugriff ermöglicht. Eine A2L Datei ist dafür nicht erforderlich. T1.stack – StackanalyseSiehe Liste der T1 Version 2.1 Features.Unterstützte Prozessoren, CompilerJede Zeile in der nachfolgenden Tabelle repräsentiert einen Satz an T1 Funktionsbiliotheken für einen bestimmten Prozessortyp und einen bestimmten Compiler.
Unterstützte Betriebssysteme
(***) T1 OS Adaptionspaket T1-ADAPT-OS erforderlich, falls 'OS Timing Hooks' nicht unterstützt werden. Unterstützte Target Interfaces
Im Downloadbereich finden sich weiterführende Informationen,
wie Produktbroschüren, Veröffentlichungen und das Timing Poster mit allgemeinen Informationen zum Thema Timing.
| 
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |
|
|
