Benefits provided by the use of TT technology from SafeTTy Systems
At SafeTTy Systems, we help our customers to develop software for embedded systems that are reliable, secure and safe using state-of-the-art “Time-Triggered” (TT) architectures that incorporate patented monitoring capabilities.
This page provides a guide to our TT 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 give examples of recent customer projects;
- 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 ‘ERES2’ book.
- You may find it useful to refer to our ‘Foundations of TT embedded systems‘ guide before reading this page.
- You may find it useful to refer to our list of Definitions while reading this page.
[This page was last updated: 2021-01-22]
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:
TT 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.
TT 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 TT architectures
In our experience, use of TT architectures (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.
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: please scroll down for further information.
Customer example: MACFAB Systems (Republic of Ireland)
Based in the Republic of Ireland, MACFAB Systems (MACFAB) specialises in the development of waste balers. MACFAB balers can reduce waste volume by up to 90%, reducing the cost of waste disposal, reducing clutter and making a cleaner, safer work environment. MACFAB offer a wide range of vertical balers, horizontal balers, small waste compactors and crushers to suit the disposal needs of their customers.
MACFAB will employ ReliabiliTTy® Technology from SafeTTy Systems in their next generation of vertical waste balers, allowing them to demonstrate compliance with IEC 61508 and related international safety standards.
Gene McMahon (Director, MACFAB) comments: “At MACFAB, our first goal is to produce balers that are safe and reliable. By working with SafeTTy Systems, we have been able to achieve what I believe to be ‘best in class’ levels of safety and reliability while also ensuring that our products continue to be extremely cost competitive.”
[7 September 2020]
Customer Example: Olitek Pty Ltd (Australia)
Based in Australia, Olitek Pty Ltd (Olitek) specialises in the development of bespoke mobile machinery that incorporates automation and robotics. In response to the worldwide COVID-19 crisis (and to help prepare for possible future events of a similar nature), the team at Olitek and their partners are currently developing a range of low-cost ‘OzVader’ medical ventilators.
Following recent discussions, the Olitek team will employ ReliabiliTTy® Technology from SafeTTy Systems in their next generation of ventilators.
James Oliver (MD, Olitek) comments: “The OzVader ventilator has been developed specifically to treat the global COVID-19 pandemic. It is designed to fulfil the needs of ICU clinicians and has safety of the patient at its forefront. By working with SafeTTy Systems, we will be able to meet our safety requirements while also ensuring that product costs can be minimised, thereby allowing us to make sure that these crucial devices can be made available wherever they are needed around the world.”
[5 June 2020]
Applying our technology: A closer look at two popular TT platforms
The figure below gives an overview of a CorrelaTTor® TT 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 book.
Design examples: TT Systems
In the majority of cases, our customers use our code frameworks to build a complete ‘TT System‘.
Here are some examples of TT Systems that are implemented using our code frameworks:
- A general-purpose automotive ECU (ISO 26262)
- A general-purpose industrial ECU (IEC 61508)
- An industrial monitoring system (IEC 61508)
- A controller for an industrial robot (IEC 61508)
- ‘Steering-Column Lock Controller’ for a high-volume passenger car (ISO 26262)
- A controller for a domestic washing machine (IEC 60730 / IEC 60335)
- A space-based control system (ECSS-E-ST-40C, ECSS-Q-ST-80C)
Design examples: TT Wrappers
In some cases, our customers use our 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 our code frameworks:
- ASIL B Linux (ISO 26262)
- Controller for an autonomous road vehicle (ISO 26262)
- Controller for a medical infusion pump that contains ‘SOUP’ (IEC 62304)
- Confirming that a machinery-operator is ‘in place’ (ISO 13849)
- Controller for a civilian aircraft system (DO-178C / DO-254)
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 …
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
‘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.