Weisse Spuren
Surprisingly different, surprisingly effective ./design2013/header-t1-4_web.png

State of the art timing analysis...

...with industry-hardened 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.

Read in the Success Stories section what our customers have to say about T1.

T1 Overview

Use Cases

  • 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.timing comes with two extension options. Add-on product T1.streaming provides the possibility to stream trace data continuously — over seconds, minutes or even days.
Add-on product T1.posix supports POSIX operating systems such as Linux or QNX.

T1 plug-ins

T1.timing comes with a modular concept and several plug-ins which are described in the following. Plug-ins can be easily enabled or disabled at compile-time using dedicated compiler switches such as T1_DISABLE_T1_CONT. To disable T1 altogether, it is sufficient to disable compiler switch T1_ENABLE which leaves the system in a state as of before the T1 integration.


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.

Key benefits include:

  • Intuitive visualization of what is actually going on in the software – it has never been easier to track down the cause of timing issues.
  • Pure software instrumentation-based approach: no hardware modification or special hardware required
  • Minimal overhead of typically only 0.2% to 0.4% CPU-load for tracing all tasks and all interrupts in a typical set-up of an ECU for engine management or chassis control
  • Detailed profiling: capturing of CPU-load and all kinds of timing parameters with min/max/average/distribution information
  • Constraints: verification of timing requirements
  • T1 offers the best insight for any target interface bandwidth:
    - Environments with low bandwidth (e. g. CAN): snapshots of a few hundred milliseconds - Environments with high bandwidth (e. g. Ethernet): streaming with real-time visualization and analysis for seconds, minutes, hours and days through add-on product T1.streaming
Click on image to enlarge
T1 Overview

Definition of timing parameters




Who said instrumentation-based tracing is not flexible and requires software compilation when moving instrumentation points around? Be prepared to see some magic when using T1.flex, the flexible on-target and at-run-time instrumentation. Select any function or even some lines of code and immediately see the corres-ponding timing parameters such as min/max/average core-execution-time (CET), delta-time (DT) and CPU-load. Click on image to enlarge
T1 Overview

Key benefits include:

  • On-the-fly instrumentation while the software is executing
  • Suitable for functions and code-fragments (providing min/max/average CET, DT, CPU-load and more)
  • Suitable also for data-accesses (providing min/max data age, access frequency)



Permanent timing analysis and timing supervision

Who or what takes care of the timing when there is no PC connected to the ECU? T1.cont provides timing analysis on the target with minimal impact on the existing software. What’s more T1.cont not only measures, it can also continuously supervise the timing – permanently making sure timing requirements are met.

Key benefits include:

  • Permanent timing analysis and timing supervision
  • Ideal for profiling the software (min/max timing parameters for selected tasks, runnables, data ages)
  • Results can optionally be stored in non-volatile memory – allowing profiling over weeks with billions of executions


Test timing-related aspects of future versions of your software today! T1.delay makes it possible by providing scalable delay routines which consume a specified amount of net-run-time. These can be placed in the schedule at places where future functionality is to be added.
Other use-cases include determination of “head-room”: an empirical way to find out how much more CET can be added before the systems is overloaded.


Around the world every night hundreds of HILs execute automated timing tests using T1. They collect timing parameters such as CPU-load, core execution time (CET), response time (RT) etc.; see also figure “Definition of timing parameters” above. At the same time they ensure no timing constraints are violated — a basis for safe and reliable embedded systems.
T1.api provides a REST API for test automation and thus is easily controllable from virtually any programming language. In test automation mode, T1 runs as a server in the background listening to commands on a configurable http port. It also provides a website with interactive documentation meaning that with a target board connected, T1.api commands can simply be sent from within the documentation. Getting a good grip on an automation interface has never been as easier.


See how timing parameters evolve over the time. Compare different versions of your software with a focus on the timing aspects. T1.diff provides numerical comparison as well as diagrams showing selected timing parameters for different versions of your software. It also allows you to configure thresholds for deviations from previous versions. T1.diff e.g. can highlight any parameter which increases or decreases by more than x% compared to the previous release eliminating the possibility for unwanted changes to slip through.


A minor but very handy feature allowing reading from and writing to arbitrary memory. The intuitive symbol browser makes navigating to the data of interest much easier.
horizontal divider

For RTOS-based projects: what is supported by T1?

For POSIX-based projects, see T1.posix.

Supported processors, compilers

Each row in the table below represents one set of T1 libraries specific to a certain processor core and a certain compiler.
Core Compiler Availability
(Variant ID)
Controller Examples
InfineonTC1.6.XTaskingV3.3.x.x (57)V3.2.1.0TC2xx, TC3xx
InfineonTC1.6.XHighTec GCCV3.1.x.x (15)V3.2.1.0TC2xx, TC3xx
InfineonTC1.6.XWind RiverShort Notice (60)

TC2xx, TC3xx
InfineonTC1.6.XGreen HillsV3.1.x.x (73)

TC2xx, TC3xx
NXP/STMe200z0-z4, z6, z7Green HillsV3.3.x.x (54) / On Request (65/72)

MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
NXP/STMe200z2, z4, z7HighTec GCCV3.1.x.x (44)V3.2.1.0MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
NXP/STMe200z2, z4, z7Wind RiverV3.1.x.x (56)V3.2.1.0MPC57xx, MPC56xx, MPC55xx, SPC58, SPC57, SPC56, etc.
ArmARMv7-R: Cortex-R4, Cortex-R4F, Cortex-R5FTexas InstrumentsV2.5.8.0 (39)

TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc.
ArmARMv7-R: Cortex-R4, Cortex-R4F, Cortex-R5FGreen HillsV3.1.x.x (78)

TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc.
ArmARMv7-R: Cortex-R4, Cortex-R4F, Cortex-R5FHighTec GCCV3.3.x.x (77)

TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc.
ArmARMv8-R: Cortex-R52HighTec CLANGShort Notice (87)

ST Stellar, NXP S32S
ArmARMv8-R: Cortex-R52Green HillsShort Notice (85)V3.2.1.0ST Stellar, NXP S32S
ArmARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 *GCCShort Notice (82)

LPC17xx, STM32F4xx, Atmel SAM V71, etc.
ArmARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 *Green HillsV3.3.x.x (83)

LPC17xx, STM32F4xx, Atmel SAM V71, etc.
ArmARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 *KeilOn Request (84)

LPC17xx, STM32F4xx, Atmel SAM V71, etc.
RenesasRH850 G3K/G3KH/G3M/G3MH/G4MHGreen HillsV3.1.x.x (52)V3.2.1.0RH850/C1x, RH850/F1x, RH850/P1x, RH850/E2x, etc.
RenesasRH850 G3K/G3KH/G3M/G3MH/G4MHWind RiverOn Request (53)

RH850/C1x, RH850/F1x, RH850/P1x, 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

VendorOperating System
ARCCOREArctic Core
CustomerAny in-house OS**
CustomerNo OS - scheduling loop plus interrupts**
ElektrobitEB tresos AutoCore OS
ElektrobitEB tresos Safety OS
KPIT CumminsKPIT**
(**) 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
CANLow bandwidth requirement: typically one CAN message every 1 to 10ms. The bandwidth consumed by T1 is scalable and strictly deterministic.
CAN-FDLow bandwidth requirement: typically one CAN message every 1 to 10ms. The bandwidth consumed by T1 is scalable and strictly deterministic.
Diagnostic InterfaceThe 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.
FlexRayFlexRay is supported via the diagnostic interface and a CAN bridge.
JTAG/DAPInterfaces 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.
Newsbox Oben
Update regarding Corona
Learn how GLIWA dealt with Corona so far. In this video message, our CEO Peter Gliwa also points out how GLIWA can help you during these rather exceptional times.

Peter Gliwa message

Interviews on YouTube
Check-out the interviews with GLIWA CEO Peter Gliwa on Matrickz TV. In this one Peter talks with MATRICKZ CEO Dr. Hasan Akram about timing in automotive software develeopment and in this one about entrepreneurship.


T1 supports TC39x
Synchronized traces from 6 cores!
T1 makes it happen. Click here, to view a screenshot of T1 with 6 synchronized traces and some cross-core communications.


More details on the AURIX 2G can be found in Infineon's official press-release.
Newsbox Unten