ReliabiliTTy® technology from SafeTTy Systems

At SafeTTy Systems, we help our customers to develop software for reliable space-based systems, automotive systems (including autonomous vehicles), industrial control systems, medical systems, railway systems, sports equipment …

We do this by developing and applying ReliabiliTTy® software frameworks that are designed to make it much easier to provide clear evidence that systems will meet ‘safety goals’ and comply with both local regulatory requirements and international safety standards.

ReliabiliTTy frameworks are based on state-of-the-art “Time-Triggered” (TT) software architectures that incorporate patented monitoring capabilities.

This page provides a guide to TT software architectures and ReliabiliTTy technology:

  • we explore the benefits that use of our technology can provide to businesses involved in the development of safety-related systems;
  • we present our views on the differences between use of a ‘TT System’ and the use of a conventional ‘Real-Time Operating System’ (RTOS);
  • we explain how ‘TT Wrappers’ can improve the safety and reliability of designs that employ a general-purpose operating systems (such as Linux™);
  • we provide a brief overview of our SafeTTy Solutions packages and SafeTTy Outsource services;
  • we provide links to a suite of public TT design examples and to our popular ‘ERES2‘ book.


[This page was last updated: 2022-06-10]empty_space


Our focus


We help our customers to develop software for reliable space-based systems, automotive systems (including autonomous vehicles), industrial control systems, medical systems, railway systems, sports equipment … 

Where required, we help our customers to achieve compliance with one or more international safety standards: ISO 26262, IEC 61508, ISO 13849, IEC 62304, IEC 60730 …

We support ‘fail safe’ and ‘fail operational’ designs (we say a little more about this below).




An overview of our approach


  • We specialise in the engineering of very simple software designs for high-reliability / safety-related / safety-critical embedded systems.
  • Keeping the designs simple allows us to model them precisely (at design time) and monitor them closely (at run time).
  • Our modelling and monitoring process allows us to provide clear evidence that the systems we support will meet their safety requirements (and the requirements of international safety standards).

Many of our customers apply our technology to build a complete ‘TT System‘.

In other cases, our customers use our technology to build a ‘TT Wrapper‘: this is a monitoring unit that is used to improve confidence in the safe operation of a (pre-existing) complex component or system.

(We say more about TT Systems and TT Wrappers in the sections below.)

To summarise: when comparing systems based ‘Real-Time Operating Systems’, conventional operating systems (such as Linux) and TT alternatives, our experience is that the world looks something like this: 



ReliabiliTTy vs. RTOS 

Two software architectures are used in embedded systems: these can be labelled as ‘event triggered’ (ET) and ‘time triggered’ (TT). The key differences between ET and TT systems arises from the way that the tasks are released.

For many developers, ET architectures are more familiar. A typical ET design will be required to handle multiple interrupts. For example, interrupts may arise from periodic timer overflows, the arrival of messages on a CAN bus, the pressing of a switch, the completion of an analogue-to-digital conversion and so on.  In an ET system, the development team is likely to write an ‘interrupt service routine’ (ISR) to deal with each of these interrupts.

In larger designs, these ISRs may be integrated into a conventional ‘Real-Time Operating System‘ (RTOS) platform.  The development team then needs to demonstrate that ISR releases (which may occur at ‘random’ points in time) and the RTOS task releases (which may occur in various combinations) can always be handled correctly.

The key advantages of RTOS / ET designs are that [i] the architecture is familiar to many developers; [ii] it is easy to build a prototype. On the other hand, a key challenge with such designs is that there may be a very large number of possible system states: this can make it very difficult to provide clear evidence that the resulting system will always operate correctly.  This, in turn, means that long test cycles (sometimes very long) can be required in order to provide evidence of compliance with safety requirements and international safety standards.

The alternative to an ET / RTOS architecture is a time-triggered (‘TT’) architecture. When saying that an embedded system has a TT architecture we mean that it executes at least one set of tasks according to a predetermined schedule.  The schedule determines the order of the tasks releases, the time at which each task is released, and whether one task can interrupt (pre-empt) another task. 

In most cases, the starting point for the implementation of a TT design is a simple task scheduler: that is, the system will not usually employ a conventional RTOS, Linux™ or Windows®. In this software framework, a single interrupt will be used, linked to the periodic overflow of a timer. A ‘polling’ process will then allow interaction with peripherals.

The deterministic behaviour of such simple TT designs means that – compared with an equivalent RTOS-based design – it is easy to provide evidence that the system will operate in compliance with its safety requirements (and international safety standards) at all times. 

We are sometimes asked by developers who are used to working with a conventional RTOS what the fundamental difference is between the design a TT system and design of an equivalent RTOS-based system.

The starting point for the two approaches is the same: both TT designs and RTOS designs are based on sets of periodic tasks.

From this common foundation, the two approaches diverge:

  • in the case of TT designs, tasks are usually co-operative (non-pre-emptive) in nature, and – in normal operation – the only active interrupt will be the periodic timer tick;
  • in the case of an RTOS-based design, task pre-emption is almost always employed, and additional (asynchronous) interrupts are usually enabled – for example, to deal with CAN messages that may arrive at ‘random’ times. 

These differences may appear small, but they have a significant impact on our ability to model the system behaviour. 

One way of thinking about this is to consider ‘MISRA® C’. 


For developers of many general-purpose embedded systems, the C programming language is a common choice.  For developers of safety-related embedded systems, use of ‘standard C’ is unusual.  Instead, a subset of the language – such as the ‘MISRA C’ subset – is much more likely to be employed.  Such language subsets are intended to improve system reliability and safety by avoiding use of features (the ‘goto’ statement is a simple example) that are known to be problematic in some designs. 

In our view the relationship between TT designs and designs based on a conventional RTOS can be viewed in a similar way (at the level of software architecture rather than programming language).  In other words: 

TT designs can be viewed as a ‘safer subset’ of a more general class of ET / RTOS designs.  TT designs have much in common with ET / RTOS designs, not least the use of periodic task sets, but they minimise (or avoid completely) the use of features – such as task pre-emption and asynchronous interrupts – that are known to make system behaviour less deterministic.




ReliabiliTTy and general-purpose operating systems (such as Linux™)

We discussed two core software architectures – TT and ET – that are used in current embedded systems in the sections above.  In that section we had a focus on TT- and RTOS-based designs.

If we look at the whole field of embedded systems more broadly, two further different categories of software development can be identified:

  • Completely ‘bare metal’ designs, that usually involve a number of interrupt services routines and a main program loop. Typically used in introductory textbooks and code examples. Usually used in practice only for very small / simple products and not discussed further here.
  • Systems based on a general-purpose OS, such as Linux.

We receive several enquiries a year from organisations that have experience developing embedded systems using a general-purpose OS (typically Linux) and now need to demonstrate compliance with international safety standards (such as IEC 61508 for an industrial-control product or ISO 26262 for an automotive product).  In these circumstances, we recommend that the organisation concerned considers the use of a TT Wrapper.



A TT Wrapper typically involves: [i] minimal changes to the Linux code or hardware; [ii] adding a low-cost MCU to the system that runs a TT software architecture and is used to monitor the behaviour of the Linux processor while the system is operating. 

TT Wrappers are  simple, cost-effective – and allow us (for example) to achieve ‘ASIL B Linux‘ for use in automotive designs.

Please note that TT Wrappers have many other applications (for example, in medical designs that involve ‘Software Of Unknown Provenance‘ – SOUP, and / or unqualified hardware). 

We provide further examples of the use of TT Wrappers later in this guide (please scroll down).     



A summary of the benefits provided to businesses by the use of ReliabiliTTy platforms

In our experience, use of ReliabiliTTy platforms (in the form of either ‘Systems’ or ‘Wrappers’) can provide the following benefits to organisations.

Evidence of compliance with safety requirements and international safety standards

  • Through the modelling, monitoring and self-test capabilities, clear evidence can be provided that the system safety requirements (and requirements of international safety standards such as IEC 62508, ISO 26262) have been met in full

Reduced development times

  • Evidence of compliance with safety requirements is generated in a fast, consistent and repeatable manner: there is no need for the long ‘fix – test – fix – test …’ cycles that can be required when the software operates in a less deterministic manner – this helps to reduce development times significantly

Reduced unit costs

  • Lightweight TT frameworks imposes a minimal processor load, and maximum (not average) processor load can be modelled precisely at design time: it is not necessary for the development team to use a more powerful MCU ‘just in case’ the software load proves to be higher than expected

Reduced corporate risk

  • Organisations can be confident that their TT products will operate safely and reliably ‘in the field’ which helps members of development teams to sleep better at night – and reduces levels of corporate risk.empty_space


Customer examples

The majority of our customer projects are carried out under NDAs and details cannot be provided.

In a small number of cases, we have permission from the organisation concerned to release project details.


Applying our technology: A closer look at two popular ReliabiliTTy platforms


The figure below gives an overview of a CorrelaTTor® platform (we pronounce it ‘correlator’).



In a CorrelaTTor platform, a single processor is employed with internal monitoring (using MoniTTor® and PredicTTor® components). For example, the combination of an ‘ASIL D’ microcontroller and CorrelaTTor software can provide a highly-effective means of meeting the requirements of ISO 26262 (up to ‘ASIL D’).

The figure below gives an overview of a DuplicaTTor® (‘duplicator’) platform.



In a DuplicaTTor platform, two processors are employed (with cross-checks between them). For example, the combination of two ‘SIL 2’ microcontrollers and DuplicaTTor software can provide an effective means of meeting the requirements of IEC 61508 (up to ‘SIL 3’) and / or ISO 13849 (up to ‘PL e’).


Does your design require ‘Fail Safe’ or ‘Fail Operational’ behaviour? 

We help our customers to use CorrelaTTor and DuplicaTTor platforms in both ‘fail safe’ and ‘fail operational’ designs. 

To summarise the difference:

  • A fail-safe design will shut down if a significant fault (that is, a fault that may prevent the system from continuing to operate safely) is detected during normal operation.
  • A fail-operational design will continue to operate (possibly in a ‘limp home’ or similar mode) if a significant fault is detected.

In general, fail-safe designs are simpler and easier to build.  However, fail-operational may be required in situation where simply shutting down is not an option (for example, in the case of an automotive design where failure may be detected when the vehicle is travelling at high speed).

As summarised in the table below, a DuplicaTTor platform will usually be required in fail-operational designs (along with an appropriate combination of microcontrollers – MCUs).  

You can learn more about CorrelaTTor and DuplicaTTor platforms in our ERES2 bookempty_space


Design examples: TT Systems


In the majority of cases, our customers use our ReliabiliTTy code frameworks to build a complete ‘TT System‘.

Here are some examples of TT Systems that are implemented using ReliabiliTTy code frameworks:




Design examples: TT Wrappers


In some cases, our customers use our ReliabiliTTy code frameworks to build a ‘TT Wrapper‘: this is a monitoring unit that is used to improve confidence in the safe operation of a (pre-existing) complex component or system.

Here are some examples of TT Wrappers that are implemented using ReliabiliTTy code frameworks:


We always recommend use of a TT System (rather than a TT Wrapper) when this is possible, because use of a System can provide higher levels of diagnostic coverage than a Wrapper, as well as increased confidence in system reliability.  However, where (for example) designs need to employ a general-purpose operating system; or other ‘Software Of Unknown Provenance’ – SOUP; or ‘unqualified’ hardware components, use of a TT Wrapper may provide the basis for a practical and effective design solution.  In addition, use of a Wrapper can provide an effective means of prototyping a safety-related system.




SafeTTy Solutions packages

We offer SafeTTy Solutions™ packages that are designed to help our customer’s development team produce TT embedded systems that are reliable, secure and safe, in compliance (where required) with one or more international safety standards: IEC 61508, ISO 26262, DO-178C, IEC 62304, IEC 60730 … 

Learn more about our SafeTTy Solutions packages …empty_space


SafeTTy Outsource services

We offer a SafeTTy Outsource™ service, where we perform some or all of the software development activity for our customer (including organising qualification by a third-party assessor, where required).

Learn more about our SafeTTy Outsource services …


Learn more about our TT technology

 eres2_front_220‘The Engineering of Reliable Embedded Systems’ (ERES2) documents an industry-proven approach to the development of software for reliable, real-time embedded systems, based on the use of TT architectures.

The case studies in ERES2 describe the development of software for the following products: [i] an industrial alarm sounder unit (IEC 61508, SIL 2); [ii] a domestic washing machine (IEC 60730, Class B); [iii] a hospital radiotherapy machine (IEC 60601-1; IEC 62304, Class C); [iv] a steering-column lock for a passenger car (ISO 26262, ASIL D); and [v] an aircraft jet engine (DO-178C, Level A).

You’ll find further information on the ERES2 page.

Our ‘ERES2’ book is accompanied by a growing suite of public ‘Time-Triggered Reference Designs’ (TTRDs).

Used in conjunction with the book, these code examples are designed to illustrate ways in which TT software architectures can be used to support the development of a wide range of embedded systems for which safety is a key design consideration.

The latest suite of public TTRDs can be downloaded from our TTRD page.