Hitex SafeTpal vs In-House Self-Test for AURIX: Choosing the Right Safety Test Strategy

Hitex SafeTpal vs In-House Self-Test for AURIX: Choosing the Right Safety Test Strategy

Safety-critical automotive systems built on Infineon AURIX TC3xx microcontrollers require runtime self-tests to detect latent hardware faults. ISO 26262 sets diagnostic coverage targets for hardware faults, most demanding at ASIL-D, though the standard’s strongest rating for any method, these targets included, is highly recommended rather than mandatory. The mechanism for meeting those targets comes down to a fundamental architectural decision: adopt Hitex’s SafeTpal package and the SafeTpack safety manager inside it, or develop custom self-test routines in-house.

Both approaches are valid. Neither is universally correct. The right choice depends on your safety architecture, hardware configuration, certification timeline, and team capabilities. This article examines both paths so Indian automotive engineering teams can make an informed decision.

What SafeTpal and SafeTpack Provide

First, the attribution, because it is routinely stated the wrong way round. SafeTpal is a Hitex product, not an Infineon one. Infineon designs the AURIX silicon; Hitex, an AURIX Preferred Design House, develops and licenses SafeTpal for it. Hitex describes SafeTpal as a safety and security offering “designed to streamline the development of safety and security for embedded systems and applications”, delivered as “a complete package consisting of software, reference design, services and trainings”.

SafeTpal is therefore a suite, not a single library. SafeTpack is the component inside it that does the hardware self-test work. Other components cover different ground: SafeThal is the hardware abstraction layer, SafeThsp the Matlab and Simulink hardware support package, SafeTschematic and SafeTdevboard the reference design and development board, with SafeTboot and SafeTsota listed as planned additions to the package.

What SafeTpack actually does. Hitex describes SafeTpack as a safety solution for the second generation of the AURIX family. It manages the complex Logic Built-In Self-Tests (LBIST) and other safety features of AURIX, and supplies functions such as program flow monitoring and cyclic control of special function registers, alongside a test handler and startup and runtime tests. Optional packages add a watchdog interface, an internal watchdog driver, an external TLF35584 and TLF35585 watchdog driver, and an enhanced Program Flow Monitor. Teams on first-generation AURIX use a different Hitex library, PRO-SIL SafeTlib.

Third-party certification, stated precisely. Hitex states that SafeTpack has achieved SIL-3 IEC 61508 certification from TÜV SÜD, and that it is developed according to ISO 26262-2018. Read what that does and does not say. The third-party certificate is an IEC 61508 SIL-3 certificate. Hitex separately states that SafeTpack “covers most safety use cases for applications according to ASIL A to ASIL D”, which is a statement about use-case coverage, not an ASIL certificate. Those are two different claims, and an assessor will treat them as two different claims. Ask Hitex for the certificate and the safety manual, and read both, before either sentence goes into your own safety case.

Defined integration model. Hitex states that SafeTpack is 100% compatible with the Infineon MCAL but can still be used independently, that it is modular so you “only pay what is used”, and that the EB tresos tool is included for configuration. Hitex also states the changeover from TC2xx SafeTlib requires no rework of handling.

Maintenance by Hitex. As new AURIX derivatives appear, Hitex extends SafeTpack. The company lists support for additional AURIX derivatives, and for the next AURIX generation (TC4xx), as work in progress rather than as shipping coverage. That offloads part of the burden of tracking errata and updating test patterns from your safety team, but if your programme targets TC4xx, confirm the current derivative list with Hitex before you build a schedule around it.

When In-House Self-Test Makes Sense

Custom self-test development becomes necessary, or at least preferable, in several scenarios that Indian automotive teams regularly encounter.

Non-standard peripheral configurations. If your ECU uses AURIX peripherals in configurations SafeTpack does not address, for instance, GTM (Generic Timer Module) in a custom PWM topology for motor control, or EVADC with application-specific channel sequencing, you need custom diagnostic routines. Hitex’s own framing is that SafeTpack covers most safety use cases, which is not the same as every possible configuration.

Custom safety mechanisms. Some safety architectures rely on application-level plausibility checks, redundant computation across lockstep cores with custom comparison logic, or external watchdog interaction patterns. These safety mechanisms are inherently application-specific and cannot be provided by a generic library.

Fault models the library does not close. If your FMEDA shows a safety-relevant element whose residual fault rate budget is not met by the mechanisms SafeTpack implements, you must supplement it with custom routines. This is common in ASIL-D powertrain applications, where the residual fault rate budget is tight and every uncovered fault mode has to be argued explicitly.

Proprietary hardware IP. If your AURIX-based design includes external safety-relevant hardware, external memory, custom ASICs on the SPI bus, or redundant sensor interfaces, the self-test strategy for those components is entirely your responsibility.

ISO 26262 Compliance Considerations

ISO 26262 Part 5 (Hardware) defines the diagnostic coverage requirements, while Part 6 (Software) governs how the self-test software itself must be developed.

Qualifying what you integrate, and qualifying your tools. A self-test library is software you ship, not a development tool, so what you owe an assessor for SafeTpack is an integration argument: evidence that it is configured, scheduled and constrained the way its safety manual requires in your specific project. Hitex supplies the certificate and the accompanying documentation; your safety manager still has to do that part. Separately, ISO 26262 Part 8 places a genuine tool-qualification obligation on the tools around the library, the compiler, the static analyser, the unit test tool. For static analysis, Perforce states that Helix QAC’s TÜV-SÜD certified qualification materials cover ISO 26262 up to ASIL D, IEC 61508 up to SIL 4 and EN 50716 up to SW-SIL 4, which reduces the effort that part of the toolchain adds to an assessment. If you develop in-house self-test routines instead, those routines must be developed according to your ASIL-rated software development process: requirements, design, implementation, unit testing, integration testing, and verification against the hardware fault models.

Traceability. Regardless of approach, you must trace each identified hardware fault mode to a specific diagnostic test, demonstrate the coverage, and show that the test executes within the required diagnostic test interval (FDTI). Hitex ships its PRO-SIL SafeTlib libraries for first-generation AURIX with a full set of safety manuals, safety cases and requirements and traceability databases. Ask Hitex for the equivalent document set for the SafeTpack release you licence, and confirm what it contains before you plan around it. In-house development requires you to build this traceability from scratch.

Assessor review. A third-party certificate and a vendor safety manual give an assessor a documented starting point and a defined set of assumptions of use to check your integration against. Custom routines have no such starting point: the assessor evaluates your fault injection methodology and your coverage argument directly. Budget review effort accordingly.

A Practical Hybrid Approach

A hybrid strategy is usually the pragmatic answer: SafeTpack for CPU, memory, and standard peripherals where its mechanisms match your fault models, supplemented by custom routines for application-specific peripherals and external hardware. This minimises development effort while closing coverage gaps.

Re-qualification effort is recurring, not one-off: each new tool version and each standard revision reopens it. Because SafeTpack sits inside the wider SafeTpal package, the certificate, the safety manual, the reference design and the training come from one vendor with one set of assumptions of use, which gives a repeatable and auditable path across multiple ECU programmes rather than a fresh argument on every project.

The critical step is a thorough FMEDA review at the start of your safety architecture phase. Map every safety-relevant hardware element to a diagnostic mechanism. Where SafeTpack covers the fault model, use it. Where it does not, budget the engineering time for custom development.

GSAS Support for AURIX Safety Projects in India

GSAS Micro Systems is an authorized Hitex partner and provides functional safety consulting for automotive teams across Bengaluru, Pune, Hyderabad, Chennai, Mumbai, Delhi NCR, and Visakhapatnam. Whether you are integrating SafeTpack into an existing AURIX platform, developing custom self-test routines for a new ECU architecture, or preparing for an ISO 26262 assessment, our safety engineering team can assist with architecture review, tool qualification, and verification strategy.

We also provide the embedded development toolchain, including Arm Keil MDK, SEGGER debug probes, and Perforce static analysis tools, that supports safety-qualified development workflows on AURIX and other automotive microcontroller platforms.

Contact GSAS for functional safety consulting →