 |
|
Surprisingly different,
surprisingly
effective
|
Timing suite
State of the art timing analysis with industry-harden methods and tools. T1 empowers and enables.
T1 is the most frequently deployed timing tool in the automotive industry, being used for many years in hundreds of mass-production projects.
As a worldwide premiere, the ISO 26262 ASIL‑D certified T1-TARGET-SW allows safe instrumentation based timing analysis and timing supervision. In the car. In mass-production. Click on one of the topics below to discover more details and read in the Success Stories section what our customers have to say about T1. 
T1 consists of the T1 target software part (T1-TARGET-SW), which runs on the target system, and the T1 host software part (T1-HOST-SW), which runs on the PC.
The target interface can be provided by CAN, FlexRay™, JTAG, or Nexus. Unlike other solutions, T1 requires very little bandwidth for communication. This explains how T1 can be used so successfully in mass-production projects, where bandwidth is typically scarce. When the data, for example scheduling trace, have been transmitted to the PC, they are visualized and analysed. The generation of reports and the facility to automate all T1 functions enable perfect integration into the testing process. The target software supports more than just the pure collection of data, however. The target system analyses the data in real-time, for example to detect whether constraints are exceeded. In this case, environment information may be saved, to allow detailed off-line analysis. In this way, even complex causes of run-time errors can be diagnosed.
T1 consists of several components called plug-ins.
T1.scope – the oscilloscope for your softwareWhether during software development, integration or verification, without the visualization of the real system there is no insight into what is actually happening on the processor.T1.scope enables this insight and puts developers, integrators and testers in the position to be able to verify the timing of their embedded software. The application is simple: the T1.scope target code collects events pertaining to the operating system, like the start and end of tasks or interrupts, and conveys them to the T1.scope component of the host software. There, the events are displayed over a time axis, just as an oscilloscope would. User-defined events can be included in the data. In addition to the graphical representation there is also the quantitative evaluation, whereby net run-times (core execution time) are calculated for tasks, interrupts, runnables, selected functions and arbitrary code fragments. The spectrum of T1.scope features is rounded off with report generation. T1.cont – on-target timing analysis and supervisionIn contrast to T1.scope, T1.cont performs the quantitative evaluation on the target itself. All instances of all tasks and interrupts are the subject of unbroken analysis, so that the computation of minimum and maximum values of timing parameters includes each occurrence. Optional Timing Constraints allow the early recognition of violations of configurable constraints. For example, a callback can be configured to be called if the net execution time of a task exceeds a given value. Combining constraints with the preservation of timing results in non-volatile memory, such as NVRAM or EEPROM, provides timing verification, which is, in practise, superior to static scheduling analysis or scheduling simulation. These model-based approaches can give an incorrect impression of safety that overlooks possible disparity between the model and reality.Like T1.scope, T1.cont supports the collection of results in the form of a report. T1.flex – flexible on-target timing measurementAs an extension to T1.scope and T1.cont, T1.flex offers the possibility, without additional instrumentation, to measure the execution time of functions and even arbitrary code fragments. The resolution of code fragment selection is one machine instruction. The measurement of access frequencies of code and data and the T1 "Data Access Inspector" (see Screenshots on this page) are performed by T1.flex. To get to the point: T1.flex enables the selection of measured code or data at run-time without having to instrument, compile and re-flash the application. This saves considerable time and money. The measured symbols are simply selected from the symbol browser and code fragments are selected in the integrated source code browser.T1.delay – injection of net execution timeBy means of T1.delay, additional net load can be configured at run-time. The places in the code where the load should occur are defined at compile-time. At run-time, the delay can be set, exact to the microsecond, and therefore the duration of the injected code. Of course, numerous such delays can be active at the same time.In addition, each delay can be periodically increased (e.g. every two seconds), in order to bring a system slowly and in a controlled way to its (timing) limits. This provides an ideal method for the empirical discovery of the "headroom", or how much spare capacity exists. T1.test – timing verification at the RTOS and code levelT1.test offers the comprehensive automation of timing measurements. The connection to the test environment is achieved using XML-based scripts triggered by a command line or a .NET interface. Integration of timing verification in existing, functional tests, typically HIL tests, is particular efficient. In this way, timing verification can be performed in parallel with the functional tests with virtually no additional test effort.T1.diff – monitoring timing as a project progressesIn the progress of every software project there are various milestones, integration levels and software versions. T1.diff supports the comparison of several software versions, delivering valuable information about how the timing of the project is developing.Not only that. T1.diff also supports the specification of thresholds, where a warning or error should be generated if they are exceeded. For example, an increase in net run-time of a runnable could be generate a warning at 10% and an error at 15%. In combination with automated tests and T1.test the development of the timing of a project can be very efficiently and accurately supervized without any manual intervention. To pick a real-world example, more and more projects rely on model-based software development with automatic code generation. With all the advantages that this approach brings, there is also one big disadvantage: the resource requirements of the software become ever more abstract. We have observed situations where an apparently minor modification of the model multiplies the execution time of the generated code by ten. This is not a problem, as long as it can be automatically detected and made transparent, e.g. with T1.diff and T1.test. T1.mod – on-line data accessDuring software development, especially with low-level software, there is again and again the need to read and modify a variable or memory cell of a running system. We need to avoid stopping the processor, which is usually required when using a debugger.T1.mod offers just this simple possibility. If an ELF file is available, the user can work with symbol names. Direct accesses to memory addresses are also possible. No A2L file is required. T1.stack – Stack-analysisSee list of T1 V2.1 features above.Supported processors, compilers
Supported RTOSs
Supported target interfaces
In Downloads you can find
more details, such as product brochures, publications and the timing poster
with general information on the subject of timing.
| 
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |
|
|
