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-08-24]
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.
Applying our technology: Design examples
In some 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.
‘TT Wrappers’ can provide an effective means of improving confidence in the safety of an existing design prototype (even where the prototype was not developed in full compliance with the relevant international safety standards). Used appropriately, a TT Wrapper can help organisations bring initial products to market quickly and safely, in a cost-effective manner.
In other cases, our customers apply ReliabiliTTy technology to build a complete ‘TT System’.
Where practical, we recommend use of a fully-TT design (rather than a TT Wrapper) in situations where the organisation needs to improve confidence in the system reliability and robustness. In some cases, we find that our customers are exploring a TT Wrapper as a first design option, to be followed by a fully-TT system for the second-generation product release. Where required, we can assist with such a ‘Wrapper first’ development process.
We have released a set of design examples that illustrate the development of both TT Wrappers and TT Systems.
ReliabiliTTy® Technology Licences
- Pont, M.J. (2018) “A framework as well as method for developing time-triggered computer systems with multiple system modes”, SafeTTy Systems Ltd, EU Patent No. 3,039,542.
- 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, UK Patent no. 2,526,082.
- Pont, M.J. (2016) “A framework as well as method for developing time-triggered computer systems with multiple system modes”, SafeTTy Systems Ltd, UK Patent no. 2,526,083.
Further patents have been applied for.
In addition, RTLs allow use of the following technology and code examples (under the terms of the customer’s specific RTL):
- the ‘Time-Triggered Reference Designs‘ (TTRDs) and related techniques described in the ‘ERES‘ books;
- complete CorrelaTTor® and DuplicaTTor® code platforms (when provided as part of a SafeTTy Solutions™ package);
- the code examples and related techniques described in the ‘PTTES‘ book.
Do you need to create an embedded system that is reliable / secure / safe?
Our ReliabiliTTy Technology Evaluation Licence (RTEL) packages provide a highly cost-effective way of exploring the benefits that our state-of-the-art TT technology can provide for your business.
- include 2 days of one-to-one design support, helping to ensure that your team can prototype their first TT product successfully, at minimal cost;
- may also include our popular TTb Training Course (delivered on your company site).
Learn more about RTEL packages …