State of the art timing analysis
with industry-hardened methods and tools.
...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.
T1.timing comes with two extension options. Add-on product T1.streaming provides the possibility to stream trace data continuously — over seconds, minutes, hours or even days. Add-on product T1.posix supports POSIX operating systems such as Linux or QNX.
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:
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 corresponding timing parameters such as min/max/average core-execution-time (CET), delta-time (DT) and CPU-load.
Key benefits include:
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:
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.
For POSIX-based projects, see T1.posix.
Each row in the table below represents one set of T1 libraries specific to a certain processor core and a certain compiler.
Silicon/IP Vendor |
Core Architecture | Compiler | Availability (Variant ID) |
ISO26262 Version Available |
Controller Examples |
---|---|---|---|---|---|
Infineon | TC1.6.X, TC1.8 | TASKING VX-toolset | V3.5.x.x (57) | V3.6.0.0 | TC2xx, TC3xx, TC4x |
Infineon | TC1.8 | TASKING SmartCode | V3.5.x.x (90) | V3.6.0.0 | TC4x |
Infineon | TC1.6.X, TC1.8 | HighTec GCC | V3.5.x.x (15) | V3.6.0.0 | TC2xx, TC3xx, TC4x |
Infineon | TC1.6.X, TC1.8 | HighTec TriCore LLVM | V3.5.x.x (91) | V3.6.0.0 | TC2xx, TC3xx, TC4x |
Infineon | TC1.6.X, TC1.8 | Wind River | V3.7.x.x (60) | on request | TC2xx, TC3xx, TC4x |
Infineon | TC1.6.X, TC1.8 | Green Hills | V3.5.x.x (73) | on request | TC2xx, TC3xx, TC4x |
NXP/STM | e200z0-z4, z6, z7 | Green Hills | V3.5.x.x (54) / On Request (65/72) | V3.6.0.0 | MPC57xx, MPC56xx, MPC55xx, SPC58xx, SPC57xx, SPC56xx, etc. |
NXP/STM | e200z2, z4, z7 | HighTec GCC | V3.5.x.x (44) | V3.6.0.0 | MPC57xx, MPC56xx, MPC55xx, SPC58xx, SPC57xx, SPC56xx, etc. |
NXP/STM | e200z2, z4, z7 | Wind River | V3.5.x.x (56) | V3.6.0.0 | MPC57xx, MPC56xx, MPC55xx, SPC58xx, SPC57xx, SPC56xx, etc. |
ARM | ARMv7-R: Cortex-R4, Cortex-R4F, Cortex-R5F | Texas Instruments | V2.5.8.0 (39) | on request | TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc. |
ARM | ARMv7-R: Cortex-R4, Cortex-R4F, Cortex-R5F | Green Hills | V3.5.x.x (78) | on request | TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc. |
ARM | ARMv7-R: Cortex-R4, Cortex-R4F, Cortex-R5F | HighTec GCC | V3.5.x.x (77) | V3.6.0.0 | TMS570LS02x/03x/04x/05x/07x, TMS570LS11x/12x/21x/31x, TMS570LC43x, etc. |
ARM | ARMv8-R: Cortex-R52 | HighTec CLANG | V3.5.x.x (87) | on request | ST SR6 Stellar, NXP S32S |
ARM | ARMv8-R: Cortex-R52 | Green Hills | V3.7.x.x (85) | V3.6.0.0 | ST SR6 Stellar, NXP S32S |
ARM | ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 * | GCC | V3.7.x.x (82) | on request | Infineon Traveo II, LPC17xx, STM32F4xx, Atmel SAM V71, etc. |
ARM | ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 * | Green Hills | V3.7.x.x (83) | V3.6.0.0 | Infineon Traveo-II, LPC17xx, STM32F4xx, Atmel SAM V71, etc. |
ARM | ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 * | Keil (ARM Compiler for Embedded) | V3.7.x.x (84) | on request | Infineon Traveo-II, LPC17xx, STM32F4xx, Atmel SAM V71, etc. |
ARM | ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 * | IAR | V3.7.x.x (69) | on request | Infineon Traveo-II, LPC17xx, STM32F4xx, Atmel SAM V71, etc. |
ARM | ARMv7-M: Cortex-M3, Cortex-M4 *, Cortex-M7 * | TASKING | V3.7.x.x (93) | on request | Infineon Traveo-II, LPC17xx, STM32F4xx, Atmel SAM V71, etc. |
Renesas | RH850 G3K/G3KH/G3M/G3MH/G4MH | Green Hills | V3.7.x.x (52) | V3.6.0.0 | RH850/C1x, RH850/F1x, RH850/P1x, RH850/E2x, etc. |
Renesas | RH850 G3K/G3KH/G3M/G3MH/G4MH | Wind River | On Request (53) | on request | RH850/C1x, RH850/F1x, RH850/P1x, RH850/E2x, etc. |
Renesas | RH850 G3K/G3KH/G3M/G3MH/G4MH | Renesas | V3.5.x.x (92) | on request | RH850/C1x, RH850/F1x, RH850/P1x, RH850/E2x, etc. |
Texas Instruments | C66x | Texas Instruments | V3.5.x.x (89) | on request | TMS320C66x, AWR2944, TDA3x |
(*) 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.
Vendor | Operating System |
---|---|
Customer | Any in-house OS** |
Customer | No OS - scheduling loop plus interrupts** |
Elektrobit | EB tresos AutoCore OS |
Elektrobit | EB tresos Safety OS |
ETAS | RTA-OS |
GLIWA | gliwOS |
HighTec | PXROS-HR |
Hyundai AutoEver | Mobilgene |
KPIT Cummins | KPIT** |
Siemens | Capital VSTAR OS |
Micriμm | μC/OS-II** |
Vector | MICROSAR-OS |
Amazon Web Services | FreeRTOS** |
WITTENSTEIN high integrity systems | SafeRTOS** |
(**) T1 OS adaptation package T1-ADAPT-OS required.
Target Interface | Comment |
---|---|
CAN | Low bandwidth requirement: typically one CAN message every 1 to 10ms. The bandwidth consumed by T1 is scalable and strictly deterministic. |
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:TCP, UDP) | TCP and UDP can be used, IP-address and port can be configured. |
FlexRay | FlexRay is supported via the diagnostic interface and a CAN bridge. |
Serial Line | Serial communication (e.g. RS232) is often used if no other communication interfaces are present. On the PC side, an USB-to-serial adapter is necessary. |
JTAG/DAP | Interfaces exist to well-known debug environments such as Lauterbach TRACE32, iSYSTEM winIDEA and PLS UDE. 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. |