What is a ‘Time-Triggered’ system?

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 comprehensive 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-02-09]



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).





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.



Monitoring TT systems at run time

One 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 in the section 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].

We have created a suite of design examples that illustrate the use of TT software architectures in designs that are compliant with IEC 61508, ISO 26262 and related standards.



‘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.





Learn more in ‘ERES2’

The Second Edition of ‘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.

In order to illustrate how the techniques presented in ERES2 can be employed in practical designs, five detailed case studies are included. These studies describe the development of embedded control and monitoring systems for the following products:

  • an industrial alarm sounder unit (IEC 61508, SIL 2);
  • a domestic washing machine (IEC 60730, Class B);
  • a hospital radiotherapy machine (IEC 62304, Class C);
  • a steering-column lock for a passenger car (ISO 26262, ASIL D);
  • an aircraft jet engine (DO-178C, Level A).

Learn more about ‘ERES2’…