Our technology

At SafeTTy Systems, we help our customers to develop software for safe and reliable embedded systems using state-of-the-art “Time-Triggered” (TT) architectures that incorporate patented monitoring capabilities.

We provide an introduction to TT architectures on this page, with a focus on the development of systems in compliance with international safety standards.

[This page was last updated: 2018-03-09]



Video introduction to TT software architectures


This 58-minute video provides an introduction to the use of TT software architectures. It explains why you might wish to consider use of such an architecture in your next safety-related embedded system.

The video includes an introduction to techniques for modelling TT systems. Mechanisms for monitoring such systems at run-time are also considered. The distinction between a ‘TT system’ and a ‘TT wrapper’ is explained. A comparison between the use of a TT software architecture and a conventional real-time operating system (RTOS) is provided.

Further information about TT software architectures can be found in our ‘PTTES‘ and ‘ERES2‘ books, and in our ‘TTb training course‘.




TT vs. ET architectures


Two software architectures are used in modern 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. To create such systems, the developer may employ a task to handle each event directly: this may involve creating an ‘interrupt service routine’ (ISR) to deal with each event. The developer may also decide to employ a conventional real-time operating system (RTOS) to support the event handling. Whether an RTOS is used or not, the end result is the same: the system must be designed in such a way that task releases – which may occur at ‘random’ points in time, and in various combinations – can be handled correctly.

The key advantage of ET designs is that they are easy to build. On the other hand, a key challenge with ET designs is that there may be a very large number of possible system states: this can make it difficult to verify that the system will always operate correctly.

The alternative to an event-triggered 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 tasks must have: [i] well-defined functional behaviour, and [ii] well-defined timing behaviour. The schedule will determine the order of the tasks are released, 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 ‘bare metal’ software framework: that is, the system will not usually employ a conventional RTOS, Linux™ or Windows®. In the 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.

A key advantage of TT designs is that it is (compared with an equivalent ET design) easy to verify that the system will operate correctly.

For this reason, TT architectures are sometimes viewed as a ‘safer subset’ of a more general class of ET architectures (just as some people consider ‘MISRA C’ to be a safer subset of the C programming language).





How does use of a TT design compare with use of a conventional RTOS?

A conventional ‘Real Time Operating System’ (RTOS) is an ‘event triggered’ – ET – design. In most cases, the system is designed to support task pre-emption, and a ‘rate monotonic’ (or similar) scheduling algorithm will be employed.

When compared with systems that employ such an RTOS, TT designs provide extremely predictable behaviour. This can, in turn, lead directly to the creation of more reliable products.

One reason that products based on TT designs tend to be more reliable is that we always know what state the system (both hardware and software) will be in when an interrupt occurs: this means that we can — when required — provide timing guarantees for key activities at resolutions measured in fractions of a microsecond on a typical modern hardware platform.

Having precise control of timing has real practical benefits. For example, it means that control and data sampling applications can provide extremely high levels of performance (with no “jitter”).

Another important implication of the use of TT designs is clear when we consider priority inversion (PI).

PI occurs in an ET system when a task of low priority can prevent a task of higher priority from running. In the worst case scenario, the result can be total deadlock (when the system “hangs” completely). Such problems can be reduced if we implement “priority ceiling” protocols correctly — but they can never be removed completely in an ET system, and PI must be considered carefully – both during design reviews and during testing.

By contrast, TT designs can be rendered completely immune to priority inversion. This provides significant benefits in many applications, including improved reliability, increased confidence in system safety, and reduced code complexity.

[Video 4 on Course TTa illustrates some of the challenges caused by priority inversion — and demonstrates why TT designs are not susceptible to this problem.]



Modelling TT systems using Tick Lists

TT approaches provide a particularly effective foundation for safety-related real-time systems because it is possible to model the expected system behaviour precisely.

This means that: [i] during the development process, it is possible to demonstrate that all of the requirements have been met; and [ii] at run time, problems can be detected very quickly.

The end result is that we can have a high level of confidence that a TT System will either: [i] operate precisely as required; or [ii] react appropriately if a problem occurs.

The key to the modelling and monitoring process is a system representation known as a ‘Tick List’.

As an example, a graphical representation of such a Tick List is shown below.



The creation and use of Tick Lists is central to the engineering of reliable TT systems.

Through the use of this simple model, we can determine key system characteristics – such as response times, task jitter levels and maximum CPU loading – very early in the design process.

We can then continue to check these characteristics throughout the development process, and during run-time operation of the system.



Use of TT systems can significantly reduce testing time – and help to minimise warranty costs

Use of a TT architecture “Greatly reduces the effort required for testing and certifying the system” [IEC 61508-3 (2010), Table C.1]

TT systems are easy to test because we always know exactly what the system should be doing at every point in time, and we can (therefore) quickly tell if something is wrong.

If your company is still using a conventional RTOS and / or an ET system design involving large numbers of interrupts, ask yourself how many people in your team really understand how this system works, in detail? Will it ever be possible to work out exactly what will happen if (say) Interrupt 10 is triggered just after Interrupt 6, while Interrupts 2 and Interrupt 3 are being serviced? Just how many possible combinations are there to consider during testing — and will you have to repeat all of the tests again after every small change?

If your team members don’t fully understand how the system operates, how can they be sure that they have really finished testing it prior to release to customers — and how can you ever know exactly how your product will operate in the field?

The predictable behaviour of TT systems — and the fact that you can be sure that your system has been fully tested before release — translates directly into lower warranty risk, and means that it is much less likely that you will ever need to recall products.

Where systems need to be maintained or upgraded in the field, a TT solution is — again — an excellent starting, point because the impact of changes to any part of the system can be predicted in advance.



Monitoring TT systems at run time

As we have seen, a key reason for choosing to use a TT software architecture is that the resulting system will have deterministic behaviour: we can therefore model key characteristics such as the maximum CPU load, the response time and levels of task jitter (as we outlined above).

Such models are necessarily based on various assumptions, including the following:

  • we have operational peripherals on each processor;
  • we can transfer data between tasks on the same processor without corruption;
  • we can transfer data between processors without corruption;
  • all the processors in our system are operating correctly;
  • we are running the correct processor software on each processor;
  • we have an operational scheduler on each processor;
  • all the tasks on each processor are operating correctly;
  • we know the ‘Worst-Case Execution Time’ (WCET) and ‘Best-Case Execution Time’ (BCET) of all tasks on each processor;
  • we know the task execution sequence in each mode on each processor.

If we fail to meet any of these assumptions at run time, our models may not be valid and we cannot be sure how the system will behave in the field.

We therefore need to incorporate mechanisms in our TT system that will allow us to test these assumptions at run time, and we need to consider what we will do if the system does not pass one or more of these tests.

When developing TT systems in compliance with international safety standards, our solutions are typically based on what we call a CorrelaTTor® (we pronounce it ‘correlator’) or DuplicaTTor® (‘duplicator’) platform. In each case, the design employs a simple TT task scheduler supported by MoniTTor and PredicTTor mechanisms: these are patented monitoring systems that were developed by the team at SafeTTy Systems.

The figure below gives an overview of a CorrelaTTor platform.



In a CorrelaTTor platform, a single processor is employed. For example, the combination of an ‘ASIL D’ microcontroller and CorrelaTTor software can provide an effective means of meeting the requirements of ISO 26262 (up to ‘ASIL D’).

The figure below gives an overview of a DuplicaTTor 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’).

Design of these platforms is discussed in detail in the ERES2 book.



Achieving compliance with international safety standards using TT systems

The team at SafeTTy Systems has been working with TT systems for more than 20 years.

In our experience, a particular benefit of this approach is that it can increase confidence in the safety of products developed in compliance with international safety standards (and significantly reduce development costs for such systems).

For example, IEC 61508 is the ‘base’ international safety standard from which many other standards – such as the automotive standard ISO 26262 – have been derived.

According to IEC 61508:

  • TT architectures are “Highly Recommended” for systems of Safety Integrity Level (SIL) 2 or above. [IEC 61508-3 (2010), Table A.2]
  • use of a TT architecture “Greatly reduces the effort required for testing and certifying the system” [IEC 61508-3 (2010), Table C.1]
  • static synchronisation of access to shared resources – a key characteristic of all TT designs — is “Recommended” (SIL3) / “Highly Recommended” (SIL4) [IEC 61508-3 (2010), Table A.2]
  • limited use of interrupts – a defining characteristic of TT designs – is “Recommended” for SIL1 and SIL2 systems and “Highly Recommended” for SIL3 and SIL4 systems. [IEC 61508-3 (2010), Table B.1].



‘Fully TT’ designs vs. ‘TT Wrappers’

When we develop safety-related embedded systems, there are two main options:

  • we can build all of the software in the system using a TT architecture; in most cases, this type of ‘fully TT’ design will also involve the use of ‘qualified’ hardware components (e.g. ‘SIL 2 ready’ or ‘ASIL D ready’ microcontrollers);
  • we can use a ‘TT Wrapper’ around parts of the system that are based on software that is not necessarily TT, and / or hardware components that may not all be fully qualified.

Whether a fully-TT design or TT Wrapper is more appropriate will depend on the needs (and design constraints) in a particular project.

We give examples of both approaches in the sections below.



How to build a ‘Fully TT’ design

In this example, we will consider the development of a sounder unit (we’ll simply refer to it as the “Sounder”) for use as part of an industrial monitoring system (IMS). The unit is to be used to sound an alarm if a fire, gas leak or another potential hazard is detected by the IMS.

In this study we are concerned only with the Sounder unit.


There are likely to be a number of Sounder units in each IMS. Each Sounder unit will (we assume) be connected to a dedicated CAN bus.

We will make the following assumptions in this example:

  • this is to be a ‘SIL 2 design’, in compliance with IEC 61508;
  • our solution is to be based on a ‘fully TT’ design.

Hazard and risk analysis

Early in the development cycle for any safety-related embedded system, we need to consider potential threats and hazards. This will include an assessment of the risks posed to users of the system or to those in the vicinity. The role of our system design process is then to include mechanisms in our design that will reduce such risks to an acceptable level.

For the Sounder, the key risk is that the alarm will not activate when it is required to do so. This could result in people being exposed to dangerous gases, fires, chemical leaks or other threats that the IMS has been designed to detect.

A secondary risk is that the alarm will sound when it is not required to do so. This may appear to be a ‘nuisance event’, but this would probably underestimate the risk involved. If, for example, the Sounder is triggered erroneously (even) once a month, this would not simply damage the reputation of the manufacturer of the unit, it would very likely to increase the probability that real alarm events would be ignored.

Selecting a TT platform

Various ‘TT platforms’ are described in the ‘ERES2‘ book: use of one of these platforms can help to simplify the process of achieving compliance with various different safety standards.

A summary of the recommended TT platforms is given in the table below.



As we have noted, this is to be a ‘SIL 2 design’, in compliance with IEC 61508. Two design options from the above table would therefore be DuplicaTTor-A-11 or CorrelaTTor-B-2.

Choices between different platform options may depend on a number of factors. For the purposes of this example, we will assume that the development team opts for ‘CorrelaTTor-B-2’ as their candidate platform, since: [i] they require a simple ‘fail safe’ design; [ii] the CorrelaTTor design is likely to result in lower unit costs than the DuplicaTTor alternative.

The architecture of the chosen platform platform is illustrated schematically in the figure below.

The resulting system architecture will then be as illustrated here:


Learn more about this example …



How to build a ‘TT Wrapper’

Use of a TT software architecture can offer many benefits, but it may not be possible for all parts of the system design.

This may be – for example – because it is necessary to incorporate some ‘unqualified’ software components in the design.

In other cases, a design based on an ASIC may incorporate a wide range of complex processors and other ‘hardware IP’, not all of which may be qualified at the required safety level.

In these circumstances, we may be able to use a ‘TT Wrapper’ to improve confidence in the safety of the whole system (or an individual component within the system).

TT Wrappers in automotive designs

In an automotive design, TT Wrappers are based on the use of what is usually called ‘ASIL decomposition’ (see ISO 26262).

Suppose (for example) that we have an automotive component that has an ‘ASIL D’ functional safety requirement (FSR).

We might decompose this FSR into a new requirement (at ‘QM(D)’ level) and a new FSR (at ‘ASIL D(D)’ level). The ‘QM(D)’ requirement will then be assigned to the ‘unqualified’ software / hardware components, and the ‘ASIL D(D)’ requirement will be assigned to the TT Wrapper.

To summarise: in such a design, all of the safety requirements will be shouldered by the TT Wrapper.



Software for a TT Wrapper is typically based on a CorrelaTTor-B platform: we illustrated such a platform in the ‘SIL 2’ example above.

The software will run on hardware that is qualified at the required ASIL level.

For example, a TT Wrapper that needs to meet ‘ASIL D(D)’ requirements will usually be implemented using an ‘ASIL D ready’ microcontroller or (in the case of an ASIC or FPGA solution) using hardware IP components – such as a ‘soft processor’ – that are ‘ASIL D ready’.



TT Wrappers in aircraft systems

In many cases, control systems for civilian aircraft – developed in compliance with DO-254 / DO-178 (and related) standards – have traditionally been based on customised processors that were designed to meet the challenges that are faced in safety-critical systems that operate at high altitudes. For example, such processors may be prone to higher levels of radiation than ground-based designs and can be designed accordingly.

In more recent designs, ‘Commercial Off The Shelf’ (COTS) processors have become more common in many aircraft designs. In such systems, the possibility that the COTS processor will ‘misbehave’ may be addressed through use of a ‘safety net’, which is defined as the employment of mitigations and protections at the appropriate level of aircraft and system design to help ensure continuous safe flight and landing.

This approach requires the safety net to be designed as a component within the aircraft system.

Use of a TT Wrapper can be an effective way of performing the required monitoring of a complex COTS processor.

Other examples of the use of TT Wrappers

We give an example of a TT Wrapper used in an automotive design here.

We give an example of a TT Wrapper used in a medical design (to deal with ‘SOUP’) here.





Full list of TT design examples (and related information)

To illustrate the application of TT architectures, various design examples are available.

Introductory material

  • You’ll find an introductory guide for people who want to learn how to program reliable, real-time embedded systems here.
  • You can view 7 hours of introductory ‘TT’ training videos here.
  • You can downloaded the complete ‘PTTES’ book (and related code examples) here
  • You’ll find some introductory material from the ‘ERES2’ book here (PDF file).
  • You’ll find various code examples from the ‘ERES2’ book here.

Automotive (ISO 26262)

  • You’ll find an automotive ECU design example (ISO 26262, ASIL D) here.
  • You’ll find an article that summarises some of the ways in which a ‘TT wrapper’ can be used to improve confidence in the safety of Level 3 / Level 4 / Level 5 road vehicles (developed in compliance with ISO 26262) here.

Industrial control / generic safety (IEC 61508)

  • You’ll find an industrial control example (IEC 61508, SIL 2) here.
  • You’ll find a TT framework that can meet IEC 61508 ‘SIL 3’ requirements using two low-cost MCUs here.

Machinery (ISO 13849)

  • You’ll find a machinery-control example (ISO 13849, ‘PLe’) here.

Medical (IEC 62304 and related standards)

  • You’ll find an article that summarises some of the ways in which a ‘TT wrapper’ can be used to improve confidence in the safety of systems that contain ‘SOUP’ (developed in compliance with IEC 62304 or other standards) here.
  • You’ll find an example that illustrates the development of a controller for a hospital radiotherapy machine (in compliance with IEC 60601-2-1 and IEC 62304) in the ‘ERES2‘ book.

Aerospace (DO-178C)

  • You’ll find an example that illustrates (in outline) the development of a controller for an aircraft jet engine (in compliance with DO-178C) in the ‘ERES2‘ book.

Household goods (IEC 60730, IEC 60335)

  • You’ll find an example that illustrates the development of a controller for a domestic washing machine (in compliance with IEC 60730 and IEC 60335) in the ‘ERES2‘ book.



ReliabiliTTy® Technology Licences

In order to support organisations that wish to develop TT embedded systems in compliance with international safety standards, we offer a range of cost-effective ReliabiliTTy® Technology Licences (RTLs).

RTLs allow use of the technology and ‘Time-Triggered Reference Designs‘ (TTRDs) described in the ‘ERES2‘ book (including all technology patented by SafeTTy Systems Ltd) in sectors ranging from aerospace, automotive, medical and industrial systems through to household goods.

At the time of writing [March 2018], RTLs allow use of the following patented technology (under the terms of the customer’s specific RTL):

  • Pont, M.J. (2017) “A framework as well as method for developing time-triggered computer systems with multiple system modes”, SafeTTy Systems Ltd, US Patent No. 9,830,211.
  • Pont, M.J. (2016) “A monitoring unit as well as method for predicting abnormal operation of time-triggered computer systems”, SafeTTy Systems Ltd, GB2526082.
  • Pont, M.J. (2016) “A framework as well as method for developing time-triggered computer systems with multiple system modes”, SafeTTy Systems Ltd, GB2526083.


Learn more about RTLs …