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.
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-06-21]
An overview of our approach
At SafeTTy Systems:
- we specialise in the engineering of very simple software designs for safety-related embedded systems;
- keeping the designs simple allows us to model them precisely (at design time) and monitor them closely (at run time);
- we achieve this goal using ‘Time Triggered’ (TT) software architectures.
Many of our 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 the state-of-the-art TT software architectures that we support in the sections below.
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.
TT vs. ET architectures
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. 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).
Design for a range of simple TT systems are presented in the ‘PTTES’ book.
Monitoring TT systems at run time
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.
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.
The TT designs that we develop for our customers will typically employ a simple TT task scheduler supported by MoniTTor and PredicTTor mechanisms: these are patented monitoring components that were developed by the team at SafeTTy Systems.
As an example, 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. 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’).
Design of these platforms is discussed in detail in the ERES2 book.
ReliabiliTTy® Technology Licences
- 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.
Further patents have been applied for.
Applying our technology
Sometimes our customers apply ReliabiliTTy technology to build a complete ‘TT System’.
Here are some examples of such systems:
- Controller for a domestic washing machine (IEC 60730 / IEC 60335, ‘Class B’)
- Developing high-reliability space-based systems (ECSS-E-ST-40C, ECSS-Q-ST-80C)
- An automotive ECU designed using ‘ASIL decomposition’ (ISO 26262, ‘ASIL B’)
- ‘Steering-Column Lock Controller’ for a high-volume passenger car (ISO 26262, ‘ASIL D’)
- Industrial monitoring system (IEC 61508, ‘SIL 2’)
- Controller for an industrial robot (IEC 61508, ‘SIL 3’)
- Determining that a machinery-operator is ‘in place’ (ISO 13849, ‘PL e’)
In other cases, our customers use ReliabiliTTy 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.
Here are some examples of TT Wrappers:
- Controller for an autonomous road vehicle (ISO 26262, ‘ASIL D’)
- Dealing with ‘SOUP’ in a medical infusion pump (IEC 62304, ‘Class C’)
- Using TT Wrappers in civilian aircraft systems (DO-178C / DO-254)
Our SafeTTy Solutions™ packages are designed to help your development team produce 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 …).
Based on state-of-the-art TT designs, each package includes a cost-effective combination of our products and services.
SafeTTy Solutions packages include an appropriate ReliabiliTTy® licence.
Learn more about SafeTTy Solutions packages …