GLIWA is a leading global provider of timing analysis, optimization, and verification tools for embedded software. The company is widely recognized for its T1 Analysis Suite and offers interdisciplinary expert services for embedded software development, particularly in the automotive industry.
GLIWA primarily serves the automotive industry, with customers including major OEMs and suppliers such as BMW, Mercedes-Benz, Audi, Volkswagen, Porsche, Ford, Bosch, Aumovio, Denso, and many others. The company's solutions are used in hundreds of mass-production projects worldwide.
Beyond automotive, GLIWA’s timing‑analysis and embedded‑software tools are also applicable across other embedded system domains that rely on deterministic real‑time behavior such as industrial, robotics, medicine, avionics and other safety‑critical embedded applications.
GLIWA provides a large portfolio covering three main areas:
GLIWA's product portfolio includes:
Add-ons for T1.timing:
GLIWA T1 Analysis Suite is a state‑of‑the‑art, software‑based timing analysis tool designed for embedded systems, especially in the automotive industry. It also includes T1.stack (for stack analysis) and T1.accessPredictor (for memory access analysis).
GLIWA provides the following products:
T1.timing is a state‑of‑the‑art, software‑based timing analysis tool designed for embedded systems, especially in the automotive industry. See T1.timing for more details.
T1.stack is a static code analysis tool that determines the stack consumption of your software. The input for T1.stack is the binary of your software (e.g. the ELF file). T1.timing can be used in the context of T1.stack to measure the branch targets of indirect function calls in order to complete the call tree. See T1.stack for more details.
T1.accessPredictor is a static code analysis tool that determines the read and write data accesses and function calls of your software. Then it compares the identified accesses and calls to a set of rules provided by the user. It will flag any violation of those rules. Think of it as an “offline MPU”. The input for T1.accessPredictor is the binary of your software (e.g. the ELF file). T1.timing can be used in the context of T1.accessPredictor to measure the branch targets of indirect function calls in order to complete the call tree. See T1.accessPredictor for more details.
T1.streaming is an add-on for T1.timing and enables recording continuous target scheduling trace data on a PC.
T1 supports POSIX operating systems through the add-on product T1.posix for T1.timing. This allows the T1-HOST-SW to visualize the sates of processes and threads over time as well as other POSIX-related information. Such POSIX traces and memory snapshots are collected by the T1-TARGET-SW for POSIX on the embedded device. The T1-TARGET-SW for POSIX is not part of the T1.posix add-on and requires a separate license.
T1.flex provides the ability to measure the runtime of any function, code, or monitor data access without instrumentation at compile time.
Yes. The T1‑HOST‑SW provides T1.api, an HTTP‑based RESTful automation interface designed for integration into CI/CD workflows. Through this API, external tools, scripts, or orchestration systems can invoke T1 functionalities such as trace download, timing analysis, and report generation. Because T1.api exposes these capabilities programmatically, it enables fully unattended execution within automated build, test, and validation pipelines.
To use T1.timing, the T1‑TARGET‑SW must be integrated into your project. As this so-called T1 Integration is a required part of the deployment, GLIWA offers professional engineering services to carry it out reliably and efficiently in close collaboration with your development team.
For most operating systems used in the automotive industry, we already have complete solutions available that require no additional integration effort. See Supported RTOSs for an overview.
In addition, T1 can be adapted to almost any real-time operating system. Even in‑house operating systems or environments based on a simple scheduling loop can be supported.
All tasks and interrupts of classical RTOS projects get traced as a result of the initial T1 Integration. This allows T1 to analyze and report standard timing parameters and visualize scheduling traces. For further analysis, T1.flex can cover most of the use-cases with its on-the-fly instrumentation. You can also add instrumentation at compile time. Typically, this is done for anything that shall be traced permanently in addition to tasks and interrupts. Such additional instrumentation includes user defined events, user defined data tracing and user defined stopwatches.
T1-TARGET-SW supports the most common compilers available on the market. The following link shows the list of supported compilers and CPU architectures. You may also contact us for additional customization.
Supported processors, compilers
T1-TARGET-SW is designed for CPU architectures rather than specific microcontrollers. T1-TARGET-SW supports the vast majority of CPU architectures on the market. The following link shows the list of supported compilers and CPU architectures. You may also contact us for additional customization.
Supported processors, compilers
The following link shows the list of supported target interfaces:
Supported target interfaces
T1‑TARGET‑SW has been extensively optimized to ensure minimal overhead. The actual overhead also depends on the configuration applied during project integration. Based on our experience, for most projects the overhead typically falls into the range 0.2% and 0.4% CPU load per CPU core. T1 has always come with a modular concept allowing users to pull in only the features required. With all plug-ins linked, T1 consumes roughly 40KBytes flash. The RAM requirements depend very much on the system setup (e.g. the number of tasks) and on the configured size of the trace buffer. Typical RAM consumption ranges between 2Kbyte and 4Kbyte per core.
Yes, the T1‑TARGET‑SW can be enabled or disabled via predefined build‑time macro switches. These switches are already provided as part of the integration package and are configured during the T1 integration.
Yes. The T1‑TARGET‑SW (for AUTOSAR CP/RTOS) is ISO 26262 ASIL‑D certified, enabling safe, instrumentation‑based timing analysis for use in automotive mass‑production ECUs.
Yes. The certified versions of the T1‑TARGET‑SW (for AUTOSAR CP/RTOS) come with a Safety Manual. This lists the requirements for the usage in safety critical projects.
GLIWA is ISO 9001, TISAX and ISO/IEC 27001certified. See also the GLIWA Quality Policy.
The T1-HOST-SW installer can be downloaded from the “Product Updates” section of our website at:
https://www.gliwa.com/downloads/product-updates/
Important: Credentials are needed for downloads, and a license is required to run T1. Both can be obtained by e-mail:
Yes. Older releases of the T1-HOST-SW are available at:
https://www.gliwa.com/downloads/product-updates/previous-releases/
To install the T1-HOST-SW on a PC without internet access follow these steps:
The integration of T1‑TARGET‑SW is performed collaboratively by a GLIWA (or distributor) engineer together with a customer‑side integrator. The process consists of two phases:
A T1 integration service is required when you want to use T1 in your project, please contact for more information.
We offer the possibility to integrate T1 into a project for evaluation purposes. To assist you with your specific requirements, please contact
Yes. Every T1‑HOST‑SW installation includes an example project, trace files, and a tutorial. In addition, examples for T1.api and the Python SDK for T1.api are provided. By default, those are installed under C:/T1.
Yes, several technical videos about T1 are available on the GLIWA YouTube channel, including tutorials on CPU load analysis, POSIX project file generation, T1.api automation, and T1.scope vs T1.cont.
Information regarding the compatibility of the T1-HOST-SW and the T1-TARGET-SW can be found in the T1-HOST-SW Help in the section “T1 Compatibility Matrix for OSEK/AUTOSAR CP systems”
A timeout error 1099 appears when T1‑HOST‑SW cannot establish a connection with T1‑TARGET‑SW. In such cases, please:
After a T1 integration a new T1 project file should be generated with every software build of your project. If the software was built by someone else, please request the corresponding T1 project file from the person who did the build.
The T1 Build ID (BID) is used to ensure that the correct version of the T1 project file is used with the build of the target software. The BID is present in the project file, in the ELF file(s) loaded by the project file into the T1-HOST-SW and in the software running on the target.
The T1-HOST-SW will show a warning if there is a mismatch with any of these three. In such cases, please:
If the issue persists, contact your T1 integrator.
For the T1-HOST-SW the documentation is available directly in the UI under Help → T1 Help… This also includes detailed descriptions of the most important use cases (see “T1 Use Cases”).
For the T1-TARGET-SW the documentation is provided at the time of the T1 integration. It is essential to use the documentation version that matches your T1‑TARGET‑SW version.
Information about T1‑TARGET‑SW bug notifications is available on the “Product Updates” page under T1‑TARGET‑SW Bug Notifications (login required).
Yes. GLIWA provides a variety of technical support and product videos on YouTube, grouped in the “Technical Support” and other T1‑related playlists.
For support inquiries, please refer to the contact details listed on the Contact page.
In the T1‑HOST‑SW, open Help → Contact Support…
There you can either:
This ensures the support team receives all required diagnostic information.
To help our support team assist you as quickly and effectively as possible, please share one of the following:
or
This information helps the support team analyze configuration, licensing, and integration details efficiently.
Yes. GLIWA offers product trainings for the T1 Analysis Suite as well as training courses on timing analysis and multi‑core timing in general. For full details, please visit the Training page.
The T1 license model distinguishes between two completely separate and independent licenses:
The T1-HOST-SW uses the CodeMeter licensing system and provides two convenient options:
For the T1‑TARGET‑SW, project‑based and platform‑based licenses are available. These licensing options allow customers to choose the most suitable model depending on how broadly the T1‑TARGET‑SW will be deployed across projects or software platforms.
No. The project‑based and platform‑based licenses allow the T1-TARGET-SW to be flashed onto any number of embedded devices of the corresponding project or platform respectively.
Please contact the GLIWA sales team or your local distributor to request a quote or to arrange a product demonstration. All relevant contact details can be found on the Contact page.
Licenses with active maintenance are entitled to receive both technical support and software updates. For support inquiries, please refer to the contact details listed on the Contact page.