• Timing measurement (e.g. max., min., average net execution times)
• Target-side timing verification (supervision)
• Automated timing tests
• Coverage of requirements, which arise from ISO 26262
• Implementation of the AUTOSAR Timing Extensions (TIMEX)
• Timing debugging: quickly detect and solve even awkward timing problems
• Exploration of free capacity, in oder to verify the timing effects of additional functionality before implementation, for example
• Investigation of dataflows and event chains and synchronization effects in multi-core projects
• Tracing of timing and functional problems without halting the target, particularly valuable in multi-core projects where it may be impractical to halt a single core

• Streaming support: New add-on product T1.streaming: Streaming of the whole trace during any period of time (minutes, hours, days; e.g. during a test drive). Analysis of the streaming trace during measurement.
• POSIX support: New add-on product T1.posix: Support of the POSIX operating systems like QNX and Linux.
• T1.cont foreground calculation: Allows the calculation of T1.cont results under extreme CPU load scenarios. Full support of cross-core activations and event-chains.
• Improved ELF/DWARF-Reader component: Load extreme huge ELF files through highly optimized and lean memory consumption. Fast project load-time.
• New communication component: Highest reliability of target communication in extreme customer scenarios. Improved diagnosis of target communication problems, simplifies troubleshooting. Fast support of new target interfaces.

• New add-on product T1.streaming: Streaming of the whole trace during any period of time (minutes, hours, days; e.g. during a test drive). Analysis of the streaming trace during measurement.
• New add-on product T1.posix: Support of the POSIX operating systems like QNX and Linux.

• New multi-core features    Version 2.1 of T1 visualizes cross-core task-activations and shows/analyzes cross-core data flow.
  

  Multi-core cross-core features

  
  
  
• DPC   "Disabled Preemption CET": high precision measurements for small functions
  T1 has always deducted the tracing overhead providing top quality measurements results. Context switches introduce an unavoidable loss of accuracy where it is not practical to observe the exact time of the switch in the OS or hardware, for interrupts. This creates a significant impact on the CET (Core Execution Time) measurement, especially for small functions. For version 2.1, we implemented the DPC feature, which allows you to precisely measure functions with execution times of only a few microseconds and below.
  
  
• Improved software-sharing support    OEMs and tier-1s mostly provide larger parts of their software as object-code only to their development partners. The new support allows for the rigourous protection of IP, whilst allowing any partner to trace and analyze the whole system on the level of TASKs and ISRs and their own software components down to the level of single machine instructions.
  
  
• Automatic overhead calibration    memory and cache configuration, code alignment etc. have an impact on the trace overhead, making it highly project-dependent and even changing from one build to the next. T1 now measures the tracing overhead; it calibrates itself automatically after every reset, removing the requirement for repeated, manual, calibration cycles throughout the project development.
  
  
• Support for more than one ELF file   In many projects, the software is divided into multiple ELF files. To reflect this, T1 now also supports such scenarios.

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.

T1 Overview

T1 Screen-shots

The T1-TARGET-SW uses highly efficient instrumentation to obtain timing-relevant information and delivers this to the T1-HOST-SW on the PC. "Highly efficient" can be quantified: in a typical 32-bit automotive application, the T1 instrumentation adds between 0.2% and 0.5% CPU Load.
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 software

Whether 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 supervision

In 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 measurement

As 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 time

By 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 level

T1.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 progresses

In 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 access

During 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-analysis

See list of T1 V2.1 features above.

Supported processors, compilers

Silicon/IP Vendor	Core	Compiler	Availability (Variant ID)	T1.stack/ T1.accessPredictor Support	ISO26262 Version Available	Controller Examples
Infineon	TC1.6.X	Tasking	V3.1.x.x (57)	✔	V2.6.0.0	TC2xx, TC3xx
Infineon	TC1.6.X	HighTec GCC	V3.1.x.x (15)	✔	V2.6.0.0	TC2xx, TC3xx
Infineon	TC1.6.X	Wind River	Short Notice (60)	✔	✗	TC2xx, TC3xx
Infineon	TC1.6.X	Green Hills	V3.1.x.x (73)	✔	✗	TC2xx, TC3xx
NXP	RCPU	Wind River	On Request (6)	✔	✗	MPC56x, MPC555, MPC53x, etc.
NXP/STM	e200z0-z4, z6, z7	Green Hills	On Request (54/65/72)	✔	✗	MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
NXP/STM	e200z2, z4, z6, z7	HighTec GCC	V3.1.x.x (44)	✔	V2.6.0.0	MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
NXP/STM	e200z2, z4, z6, z7	Wind River	V3.1.x.x (56)	✔	✗	MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
Arm	ARMv7-R Cortex-R4 Cortex-R4F Cortex-R5F	Texas Instruments	V2.5.8.0 (39)	✔	✗	TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc.
Arm	ARMv7-R Cortex-R4 Cortex-R4F Cortex-R5F	Green Hills	V3.1.x.x (78)	✔	✗	TMS570LS02x/03x/04x/05x/07x TMS570LS11x/12x/21x/31x TMS570LC43x etc.
Arm	ARMv7-M Cortex-M3 Cortex-M4 * Cortex-M7 *	GCC	Short Notice (82)	✔	✗	LPC17xx, STM32F4xx, Atmel SAM V71, etc.
Arm	ARMv7-M Cortex-M3 Cortex-M4 * Cortex-M7 *	Green Hills	On Request (83)	✔	✗	LPC17xx, STM32F4xx, Atmel SAM V71, etc.
Arm	ARMv7-M Cortex-M3 Cortex-M4 * Cortex-M7 *	Keil	On Request (84)	✔	✗	LPC17xx, STM32F4xx, Atmel SAM V71, etc.
Renesas	RH850 G3K/G3M	Green Hills	V3.1.x.x (52)	✔	V2.6.0.0	RH850/C1x, RH850/F1x, RH850/P1x, etc.
Renesas	RH850 G3K/G3M	Wind River	On Request (53)	✔	✗	RH850/C1x, RH850/F1x, RH850/P1x, etc.
Renesas	RH850 G4MH	Green Hills	V3.1.x.x (52)	✔	✗	RH850/E2x, etc.

(*) Cortex-M4 adds DSP and FPU to Cortex-M3. Cortex-M7 further adds a 64-bit bus and double precision FPU. T1 uses the shared sub-set of the instruction sets.

Supported RTOSs

Vendor	Operating System
ARCCORE	Arctic Core
Customer	Any in-house OS**
Customer	No OS scheduling loop plus interrupts**
Delphi	PharOS**
Elektrobit	EB tresos AutoCore OS
Elektrobit	EB tresos Safety OS
Elektrobit	proOSEK**
Elektrobit	OSEKtime**
ETAS	RTA-OS
ETAS	RTA-OSEK**
ETAS	ERCOSEK**
GLIWA	gliwOS
HighTec	PXROS-HR
KPIT Cummins	KPIT**
Mentor	VSTAR OS
Micriμm	μC/OS-II**
Vector	MICROSAR-OS***
Vector	osCAN**

(**) T1 OS adaptation package T1-ADAPT-OS required.
(***) T1 OS adaptation package T1-ADAPT-OS required if 'OS Timing Hooks' are not supported.

Supported target interfaces

Target Interface	Comment
CAN/ CAN FD	Low bandwidth requirement: typically one CAN message every 1 to 10ms. The bandwidth consumed by T1 is scalable and strictly deterministic.
Diagnostic Interface	The diagnostic interface supports ISO14229 (UDS) as well as ISO14230, both via CAN with transportation protocol ISO15765-2 (addressing modes 'normal' and 'extended'). The T1-HOST-SW connects to the Diagnostic Interface using CAN.
Ethernet (IP/UDP)	UDP is used, IP-address and port can be configured.
FlexRay	FlexRay is supported via the diagnostic interface and a CAN bridge.
JTAG/ DAP	Interfaces exist to well-known debug environments such as Lauterbach TRACE32 and iSYSTEM winIDEA. The T1 JTAG interface requires an external debugger to be connected and, for data transfer, the target is halted. TriCore processors use DAP instead of JTAG.

In Downloads you can find more details, such as product brochures, publications and the timing poster with general information on the subject of timing.