• 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

• T1.stack – a combination of static and measurement based stack-analysis, unique in the world    T1.stack disassembles the executable, typically the ELF file, derives the call-tree and determines the stack-usage of each function. The result is nicely visualized as the screen-shot shows. Click on it for a full-size view.
  Static code analysis is limited in principle and cannot e.g. resolve all kinds of indirect function calls. Indirect function calls are used frequently in automotive software.

  T1.stack

  Other stack analysis tools based on static code analysis have to rely on manual annotation. These are error-prone since in most projects no developer has access to and knowledge about all parts of the software.
  With a few mouse-clicks, T1.stack resolves indirect function calls based on measurements removing the problem of the error-prone manual annotations described above and reducing the effort for annotations significantly. T1.stack has always unlimited access to all parts of the software.
  
  
• 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	T1.flex also available	T1.stack Support	ISO26262 Version available	Controller Examples
Infineon	TC1.3.1	Tasking	Yes	Yes	No	TC1797, TC1767, TC1736
Infineon	TC1.3.1	HighTec GCC	Yes	Yes	No	TC1797, TC1767, TC1736
Infineon	TC1.6	Tasking	Yes	Yes	No	TC1798, TC1793, TC1791, TC178x, TC172x
Infineon	TC1.6	HighTec GCC	Yes	Yes	No	TC1798, TC1793, TC1791, TC178x, TC172x
Infineon	TC1.6.X	Tasking	Yes	Yes	Yes (V2.6.0.0)	TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x
Infineon	TC1.6.X	HighTec GCC	Yes	Yes	Yes (V2.6.0.0)	TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x
Infineon	TC1.6.X	Wind River	Yes	Yes	No	TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x
Infineon	TC1.6.X	Green Hills	Yes	Yes	No	TC29x, TC27x, TC26x, TC23x, TC22x, TC21x, TC39x
NXP	RCPU	Wind River	Yes	Yes	No	MPC56x, MPC555, MPC53x
NXP/STM	e200z0-z4, z6, z7	Green Hills	Yes	Yes	No	MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56
NXP/STM	e200z0-z4, z6, z7	HighTec GCC	Yes	Yes	Yes (V2.6.0.0)	MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56
NXP/STM	e200z0-z4, z6, z7	Wind River	Yes	Yes	No	MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56
ARM	ARMv7-R Cortex-R4 Cortex-R4F Cortex-R5F	Texas Instruments	Yes	Yes	No	TMS570LS02x/03x/04x TMS570LS05x/07x/11x/12x/21x/31x TMS570LC43x
ARM	ARMv7-M Cortex-M3 Cortex-M4 * Cortex-M7 *	GCC	Yes	Yes	No	LPC17xx STM32F4xx Atmel SAM V71
ARM	ARMv7-M Cortex-M3 Cortex-M4 * Cortex-M7 *	Green Hills	Yes	Yes	No	LPC17xx STM32F4xx Atmel SAM V71
ARM	ARMv7-M Cortex-M3 Cortex-M4 * Cortex-M7 *	Keil	Yes	Yes	No	LPC17xx STM32F4xx Atmel SAM V71
Renesas	V850E	Green Hills	Yes	Yes	No
Renesas	V850E2	Green Hills	Yes	Yes	No	V850E2/Fx4-L
Renesas	RH850 G3K/G3M	Green Hills	Yes	Yes	Yes (V2.6.0.0)	RH850/C1x, RH850/F1x, RH850/P1x
Renesas	RH850 G3K/G3M	Wind River	Yes	Yes	No	RH850/C1x, RH850/F1x, RH850/P1x
Renesas	RH850 G4MH	Green Hills	Yes	Yes	No	RH850/E2x
Renesas	SH2A	Renesas	Yes	No	No	SH725x, SH72Ax
Infineon	C166SV2	Tasking	Yes	Planned	No	XC22xx, XC23xx, XC27xx
NXP	CPU12/CPU12X	Metrowerks	No	No	No	HC12/S12/S12X
Atmel	AVR	GCC	No	No	No	e.g. ATmega32, ATmega64, ATmega128

(*) 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
GLIWA	gliwOS
ETAS	ERCOSEK**
Vector	MICROSAR-OS**
Vector	osCAN**
Delphi	PharOS**
Micriμm	μC/OS-II**
Elektrobit	proOSEK
Elektrobit	OSEKtime**
Elektrobit	EB tresos AutoCore OS
Elektrobit	EB tresos Safety OS
ETAS	RTA-OSEK
ETAS	RTA-OS
KPIT Cummins	KPIT**
ARCCORE	Arctic Core
HighTec	PXROS-HR
Customer	Any in-house OS**
Customer	No OS scheduling loop plus interrupts**

(**) T1 OS adaptation package T1-ADAPT-OS required

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.