introduction and applications - time-triggered solutions · this document introduces the...

DuplicaTTor® Design Suite 0405

Introduction and Applications

Document ID: DDS-0405-R001-IA-V02B Document release date: 18 January 2019

Product ID to which document applies: DDS-0405-R001 Target hardware: DEB-0405-R002

External Watchdog Controller(eWDC)

MODE / STATE Data

Task Sequence Data(for MCU-B)

Task Data

STM32-F405TT scheduler

Task sets A x 1

PROCESSOR

ResetMechanism

PROCESSOR

ConfigurationMechanism

PredicTTor® Mechanism

MoniTTor® Mechanism

Internal Watchdog Timer(iWDT)

MCU-A

MODE / STATE Data

Task Sequence Data(for MCU-A)

Task Data

STM32-F405TT scheduler

Task sets B x 1

PROCESSOR

ResetMechanism

PROCESSOR

ConfigurationMechanism

PredicTTor® Mechanism

MoniTTor® Mechanism

Internal Watchdog Timer(iWDT)

MCU-B

DDS-0405-R001-IA-V02B – COPYRIGHT © 2017-2019 SAFETTY SYSTEMS LTD

Conditions of Use

The ‘DuplicaTTor® Design Suite’ (DDS) with Product ID ‘DDS-0405-R001’ is provided to customers under the

terms of a ReliabiliTTy® Technology Licence (RTL) or ReliabiliTTy® Technology Evaluation Licence (RTEL).

Any and all use of this product shall comply with the terms of the corresponding RTL / RTEL.

Please refer to your RTL / RTEL for details.

Document revisions

DDS-0405-R001-IA-V01A (2017-11-06) Original public release.

DDS-0405-R001-IA-V02A (2018-11-23) Revised list of examples. Updates throughout the document to improve readability.

DDS-0405-R001-IA-V02B (2019-01-18) Minor changes to cross-references to match latest release of User Guide.

Trademarks

CorrelaTTor, DecomposiTTor, DuplicaTTor, MoniTTor, PredicTTor, ReliabiliTTy, SafeTTy, SafeTTy Systems,

TriplicaTTor and WarranTTor are registered trademarks or trademarks of SafeTTy Systems Ltd in the UK and

other countries.

ARM® and Keil® are registered trademarks of ARM Limited.

All other trademarks acknowledged.


Contents

Conditions of Use .............................................................................................................................................. 2

Document revisions ........................................................................................................................................... 2

Trademarks ........................................................................................................................................................ 2

Contents ............................................................................................................................................................ 3

Related documentation ..................................................................................................................................... 4

Related international standards and guidelines ................................................................................................ 5

1. Introducing the DDS-0405 and DDS-0405-EC ................................................................................................ 7

2. Key features of the DDS-0405-EC .................................................................................................................. 7

3. Fail-Safe LEDs vs. Fail-Safe Switches .............................................................................................................. 7

4. Potential applications for the DDS-0405-EC: Overview................................................................................. 9

5. Industrial control (IEC 61508) ...................................................................................................................... 10

a) Key system and safety requirements ...................................................................................................... 10

b) Relevant international safety standards ................................................................................................. 10

c) Outline design .......................................................................................................................................... 11

d) Related design examples ......................................................................................................................... 11

6. Machinery sensor (IEC 61508, ISO 13849) .................................................................................................. 12



c) Outline design .......................................................................................................................................... 13

d) Other potential applications for this ‘OiP’ system .................................................................................. 13

7. Battery Management System for vehicle (ISO 26262, ISO 13849) .............................................................. 14



c) Outline design .......................................................................................................................................... 15

d) Related design examples ......................................................................................................................... 15

8. Medical HMI (IEC 60601, IEC 62304, IEC 61508) ......................................................................................... 16



c) System modules ....................................................................................................................................... 16

d) Outline designs for the TCP and LINAC-C modules ................................................................................. 17

e) Related design examples ......................................................................................................................... 17

9. Household control (IEC 60730, IEC 60335) .................................................................................................. 18



c) Outline design .......................................................................................................................................... 19

10. Aerospace control (DO-178C) .................................................................................................................... 20

a) Introduction ............................................................................................................................................. 20

b) Design example ....................................................................................................................................... 21

11. The need for ‘Limp home’ and backup systems ........................................................................................ 22

12. Working with alternative hardware targets .............................................................................................. 22

13. Conclusions ................................................................................................................................................ 22


Related documentation

This document should be read in conjunction with1:

[D1] Pont, M.J. (2016) “The Engineering of Reliable Embedded Systems”,

ISBN: 978-0-9930355-3-1 (‘International Hardback Edition 2.3’ or later); or,

Pont, M.J. (2017) “The Engineering of Reliable Embedded Systems”,

ISBN: 978-0-9930355-4-8 (‘International Paperback Edition 2.3’ or later); or,

Pont, M.J. (2017) “The Engineering of Reliable Embedded Systems”,

ISBN: 978-0-9930355-5-5 (‘Indian Paperback Edition 2.3’ or later).

[D2] DuplicaTTor Design Suite 0405: Introduction and Applications

(Document ID ‘DDS-0405-R001-IA-V02B’, or a later version of this document)

[D3] DuplicaTTor Design Suite 0405: User Guide

(Document ID ‘DDS-0405-R001-UG-V01B’, or a later version of this document)

[D4] The DuplicaTTor Evaluation Board 0405 User Guide

(Document ID ‘DEB-0405-R002-UG-V01C’, or a later version of this document)

[D5] The DuplicaTTor Evaluation Board 0405 Hardware Guide

(Document ID ‘DEB-0405-R002-HG-V01A’, or a later version of this document)

1 To ensure consistency in referencing in all DDS-405 guides, this list includes the document in which it appears.


Related international standards and guidelines

Reference in text Full reference

Industrial / Machinery

IEC 61508 IEC 61508: 2010

ISO 13849-1 ISO 13849-1: 2015

Automotive

ISO 26262 ISO 26262: 2018

Household goods

IEC 60730 IEC 60730-1: 2013

IEC 60335

IEC 60335-1: 2010 + A1: 2013

Medical

IEC 60601-1 IEC 60601-1: 2005 + AMD1: 2012 IEC 60601-1-8 IEC 60601-1-8: 2006 + AMD1: 2012 IEC 60601-2-1 IEC 60601-2-1: 2009 + AMD1: 2014

IEC 62304 IEC 62304: 2006 + AMD1: 2015

Civil aerospace

DO-178C DO-178C: 2012

Generic (coding)

MISRA C MISRA C: 2012 (March 2013)


www.SafeTTy.net

http://www.safetty.net/


1. Introducing the DDS-0405 and DDS-0405-EC

This document introduces the ‘DuplicaTTor® Design Suite’ (DDS) with Product ID ‘DDS-0405-R001’: the

abbreviated identifier ‘DDS-0405’ will be used throughout the remainder of this document to refer to this

product.

The DDS-0405 package is based around an ‘example configuration’ (the ‘DDS-0405-EC’, see Figure 1).

When the DDS-0405-EC is adapted in accordance with the guidelines presented in D12, the DDS-0405

package is intended to facilitate the rapid development of ‘Time Triggered’ (TT) systems in compliance with

a range of international safety standards (see Section 4).

The DDS-0405-EC can be used ‘out of the box’ with the DuplicaTTor Evaluation Board 0405 (DEB-0405).

The DEB-0405 incorporates two STM32F405 microcontrollers (MCUs): please refer to D4 and D5 for further

information.

The DDS-0405-EC also provides support for the collection of key timing measurements, including ‘Worst-

Case Execution Time’ (WCET) and ‘Best Case Execution Time’ (BCET) and scheduler jitter.

2. Key features of the DDS-0405-EC

The key to understanding the operation of the DDS-0405-EC is to appreciate that the software framework is

intended to perform two activities: [i] (self) monitoring; [ii] safety-related actions.

Informally, the operation of the DDS-0405-EC can be summarised as follows:

the system enters a fail-safe state if either MCU detects a problem during the monitoring process;

the system performs a safety-related action only if both MCUs agree to this.

As an additional safety net, there is an external ‘watchdog controller’ (eWDC): the eWDC is designed to

force the system into a fail-safe state even if both MCUs start operating incorrectly. This might be

necessary if (for example) both MCUs could be damaged by a ‘Common-Cause Failure’ (e.g. overvoltage).

3. Fail-Safe LEDs vs. Fail-Safe Switches

When considering the operation of the DDS-0405-EC, it is important to be clear that - in a complete

application or product - it is expected that each Fail-Safe LED will be replaced by an appropriate Fail-Safe

Switch: see Figure 2.

When a Fail-Safe LED is ‘ON’, it is assumed: [i] that the corresponding switch is ‘open’; and [ii] that the

‘Equipment Under Control’ is (therefore) in a Fail-Safe State.

Figure 3 gives a more complete example. In this automotive design, the three switches (in series) provide

power to the transceiver unit. If one or more switch is open, the transceiver will be disabled: this helps to

ensure that the sensor unit cannot send erroneous data to the main vehicle control system in the event

that one or more of the MCUs malfunctions.

2 Full references to ‘D1’ and other related documents are given on p.4.


Figure 1: An overview of the DDS-0405-EC.

Figure 2: In a complete application, it is expected that each Fail-Safe LED will be replaced with an appropriate ‘Fail-Safe Switch’.

Figure 3: In this automotive, the three switches (in series) provide power to the transceiver unit. See text for details.

MCU-A

MCU-B

eWDC

Fail-Safe LED (A)

Fail-Safe LED (B)

Fail-Safe LED (eWDC)

BTN (B)(‘Open’)

Switch count (MCU-A)

Switch count (MCU-B)

UART3 / USB reports (MCU-A)

UART3 / USB reports (MCU-B)

BTN (A)(‘Open’)

Heartbeat LED (A)Control LED (A)

Heartbeat LED (B)Control LED (B)

[EUC power supply]

Equipment Under Control

MCU-A

MCU-B

eWDC

FS-A (Green LED ‘ON’ means switch is ‘open’)

FS-B (Green LED ‘ON’ means switch is ‘open’)

FS-WDC (Green LED ‘ON’ means switch is ‘open’)

[Transceiver power supply]

Transceiver

MCU-A

MCU-B

eWDC

Serial comm. link

FS-A

FS-B

FS-WDC

Camera Module A

Camera Module B


Table 1: Potential applications for the DDS-0405.

[1] DDS-0405 is primarily intended as an effective foundation for ‘SIL 3’ / ‘ASIL D’ / ‘PL e’ / ‘Class C’ and equivalent designs developed in compliance with a range of international safety standards.

[2] When developing ‘SIL 4’ and equivalent designs, an heterogeneous hardware platform may be required. In these circumstances DDS-0405 can be provide an effective prototyping platform: see Section 10.

[3] Use of DDS-0405 is not recommended for ‘SIL 0’ (and equivalent) designs: please refer to D1 for alternative design solutions.

[4] DDS-0405 can be employed in ‘SIL 1’ / ‘SIL 2’ (and equivalent) designs but may not be necessary: please consider a CorrelaTTor platform (presented in D1) as a cost-effective alternative.

Generic (IEC 61508)

(SIL 0) SIL 1 SIL 2 SIL 3 SIL 4

Machinery (ISO 13849)

PL a PL b / PL c PL d PL e --

Household (IEC 60730)

Class A Class B Class C --

Medical (IEC 62304)

Class A Class B Class C

Automotive (ISO 26262)

QM ASIL A ASIL B /

ASIL C ASIL D --

Civil Aerospace (DO-178C)

Level E Level D Level C Level B Level A

Use DDS-0405? [3] [4] [1]

[2]

4. Potential applications for the DDS-0405-EC: Overview

While the visible functionality of the DDS-0405-EC is limited, the underlying self-test and monitoring

framework is comprehensive and is capable of providing a highly-effective foundation for a wide range of

safety-related products.

For example, when the DDS-0405-EC is adapted in accordance with the techniques described in D1,

the DDS-0405 package is intended to facilitate the rapid development of fail-safe:

industrial controllers in compliance with IEC 61508 – see Section 5;

machinery systems in compliance with IEC 61508 and ISO 13849 – see Section 6;

vehicle systems in compliance with ISO 26262 and / or ISO 13849 – see Section 7;

medical equipment in compliance with IEC 62304 – see Section 8;

household goods in compliance with IEC 60730 / IEC 60335 – see Section 9;

civil aircraft designs in compliance with DO-178C – see Section 10.

A summary of some of the potential applications for the DDS-0405-EC is given in Table 1.

PLEASE NOTE

The DDS-0405-EC is primarily intended to support the development of ‘fail safe’ components, with

requirements that might be summarised (informally) as: ‘do what you are required to do or shut down’.

Fail-safe behaviour is common in components that are employed in safety-related designs, but not all

systems have fail-safe requirements.

Some notes about the development of ‘Limp Home’ and related systems are included in Section 11.


5. Industrial control (IEC 61508)

a) Key system and safety requirements

This design example considers a controller for an industrial robot (Figure 4).

The core system requirements in this example are superficially very simple: [i] when the ‘Robot Control

Unit’ (RCU) receives commands over the serial communication link, it shall ensure that the robot carries out

the commands correctly; [ii] if the RCU cannot operate in compliance with the commands, it shall ensure

that the robot enters a ‘fail safe’ state.

b) Relevant international safety standards

It is assumed that this system is to be developed in compliance with international standard IEC 61508.

IEC 61508 is concerned with functional safety, achieved by means of systems that are implemented

primarily in electrical and/or electronic and/or programmable electronic technologies (for example, using

microcontrollers – MCUs – and appropriate software).

Hardware Fault Tolerance (HFT) is a key consideration in many IEC 61508 designs.

When HFT = 0, this means that there is only a single processing path available.

If this path fails, it may be challenging to: [i] detect this failure; and [ii] ensure that the system can enter

an appropriate ‘Fail-Safe State’.

When HFT = 1, this means that there is a second (independent) processing path available: if one

processing path fails, the second processing path is intended to be able to both detect this failure and

act appropriately (typically by forcing the system into an appropriate Fail-Safe State).

To achieve compliance with IEC 61508 at ‘SIL 3’ level, many designs employ an HFT of 1.

Figure 4: An overview of the Robot Control Unit (RCU) that is the subject of this design example.

Robot Control

Unit

Serial comm. link(e.g. to PLC)

Rx: Commands

Tx: Status


Figure 5: An outline RCU design based on DDS-0405-EC.

c) Outline design

It will be assume that it has been determined that the RCU must be developed in compliance with

IEC 61508 at ‘SIL 3’, using an architecture with HFT of 1.

Building on the foundation provided by the DDS-0405-EC, the design outlined in Figure 5 could be

employed to meet these requirements.

In this example it is assumed that:

the RCU will perform control function (that is, it will cause the robot to move in accordance with

directions received over the serial communications link);

the RCU will monitor the operation of the robot to ensure that it moves as directed;

the RCU will perform internal ‘self checks’, to ensure that it is operating correctly (the dual-MCU

architecture will have a central role to play in such checks);

if problems are detected in any of the control or monitoring operations, the RCU will ensure that at

least one of the Fail-Safe Switches (FS-A, FS-B, FS-WDC) is opened, thereby disabling the drive unit and

causing the robot to stop in what is assumed to be a fail-safe state.

d) Related design examples

As outlined in Figure 5, this design involves receipt of commands over a serial link.

Many control systems take this form (for example in medical systems, aerospace systems, automotive

systems, …).

For example, a braking unit in a passenger car might employ a similar architecture: please see Section 7 for

another automotive example.

[Drive power supply]

Drive Unit

MCU-A

MCU-B

eWDC

Serial comm. link(e.g. to PLC)

FS-A

FS-B

FS-WDC


6. Machinery sensor (IEC 61508, ISO 13849)


In this example, the aim is to ensure that the operator of a piece of equipment is alert: if (for example) the

operator falls asleep, becomes ill or leaves his or her position for some other reason, the equipment that

the operator is responsible for must be shut down safely.

Such an ‘Operator in Place’ (OiP) monitoring facility has many potential applications: some of these are

considered in Section 6d.

In this example, it will be assumed that the OiP system is to be applied in the piece of machinery illustrated

in Figure 6.


It is assumed that this system is to be developed in compliance with ISO 13849 and IEC 61508.

IEC 61508 was considered (briefly) in Section 5b.

ISO 13849-1 provides safety requirements and guidance on the principles for the design and integration of

safety-related parts of control systems (SRP/CS), including the design of software, for a wide range of

machinery. This standard includes a set of 5 ‘designated architectures’ (DAs): using one of these DAs may

help to make it easier to demonstrate compliance with the standard. As an example, Figure 7 represents a

Category 4 designated architecture.

Figure 6: The intended target for the ‘Operator in Place’ system.

Figure 7: An overview of a ‘Category 4’ designated architecture from ISO 13849.

Sensor Suite A Processor Unit A Actuator Suite A

Sensor Suite B Processor Unit B Actuator Suite B


Figure 8: An outline OiP design based on DDS-0405-EC.

c) Outline design

Figure 8 illustrates an outline design for an OiP system that is intended to meet both IEC 61508 (‘SIL 3’) and

ISO 13849 (Category 4 / PL e) requirements.

Building on the DDS-0405-EC foundation, this design employs two low-cost camera modules and

appropriate processing to ensure that the machine can only move if there is an alert operator in the cab.

To achieve this, some of the following operations might need to be performed: [i] the images of the cab would be checked against stored examples to ensure that the operator was sitting in the correct seat position; [ii] images taken in sequence would be checked to ensure that the driver was moving about (a little), as would be expected from an alert person.

d) Other potential applications for this ‘OiP’ system

It might be argued that an OiP system similar to that presented here should be included in all heavy

vehicles that operate on public roads, and particularly to vehicles – such as passenger coaches and school

buses – that carry passengers. Similarly, rail vehicles – including both trains and trams – may benefit from

such a system (see Figure 9).

Figure 9: Another possible target for the OiP system.

[Excavator drive power supply]

Excavator Drive

MCU-A

MCU-B

eWDC

Camera Module A

Camera Module B

FS-A

FS-B

FS-WDC


7. Battery management system for vehicle (ISO 26262, ISO 13849)


There are increasing concerns across the world about pollution levels in city environments. One

consequence of this is a move towards the use of various forms of electric vehicle. Such concerns now

apply to both ‘on road’ vehicles (such as passenger cars, trucks and buses) and various forms of ‘off road’

vehicle (such as agricultural, mining and airport-transport vehicles).

Such vehicles require a battery supply. While the vehicle is in use or being charged, this battery supply

must be monitored (for example, to detect and handle situations where a cell overheats) and controlled

(for example, to ensure that the voltages across different cells in the battery pack are ‘balanced’, and to

allow the supply to be disconnected from the vehicle in the event that problems are detected).

This example considers, in outline, the requirements for a ‘Battery Management System’ (BMS) for such a

vehicle.


Most control and monitoring systems for on-road vehicles are developed in compliance with ISO 26262.

ISO 26262 is the adaptation of IEC 61508 (introduced in Section 5b) to comply with needs specific to the

application sector of electrical and/or electronic (E/E) systems within on-road vehicles. This adaptation

applies to all activities during the safety lifecycle of safety-related systems comprised of electrical,

electronic and software components. The latest version of this standard (ISO 26262: 2018) applies to

passenger cars, trucks, buses and motorcycles.

A range of different standards apply for off-road vehicles, depending on the particular sector (e.g.

agriculture or mining). In many cases, ISO 13849 (introduced in Section 6b) represents a common ‘base

standard’ which many designs need to comply with.

In many cases, even off-road designs will sometimes be used on public roads (for example, where farmers

moving equipment between fields): in this case, products may need to meet both ‘on road’ and ‘off road’

requirements. In addition, suppliers of vehicle components may wish to ensure that these components can

be used in as wide a range of vehicles as possible, by ensuring compliance with both ‘on road’ and ‘off road’

standards.

In the case of semi and fully-autonomous vehicles (which in some respects operate like existing machinery

designs) development in compliance with ISO 13849 may also be considered appropriate.

For the above reasons, it will be assumed that the BMS design considered in this section needs to comply

with both ISO 26262 and ISO 13849.

Figure 10: An example of ASIL decomposition.

ASIL B (D) ASIL B (D)

ASIL D


c) Outline design

It will be assumed that the BMS unit has at least one ‘Functional Safety Requirement’ (we’ll call it ‘FSR-1’)

that has been assessed as being of ‘ASIL D’ (ISO 26262) and ‘PL e’ (ISO 13849).

As noted in Section 6b, meeting such ISO 13849 requirements will typically involve use of two

microcontrollers with cross-checks between them. If we also wish to have our BMS design comply with ‘on

road’ requirements we would wish to find a similar architecture that is compliant with ISO 26262.

In this example, we will assume that – through a process of ‘ASIL decomposition’ (as defined in ISO 26262)

– FSR-1 can be decomposed into two new FSRs (FSR-1a and FSR-1b), each of which is ASIL B (D).

As discussed in D1 (Appendix 3), the two new FSRs must be implemented independently (and it must be

possible for the development team to demonstrate – clearly and unambiguously – that the two

implementations are independent).

One way of providing an independent implementation is to begin by allocating FSR-1a and FSR-1b to

different MCUs (with appropriate cross-checks between them). If we follow this approach, then there are

clear parallels between the required ‘on road’ and ‘off road’ architectures.

Figure 11 shows a possible architecture for a BMS that is intended to meet the FSR-1a / FSR-1b

requirements.

d) Related design examples

Use of the dual-processor architecture outlined in this example may offer safety, reliability and business

benefits when developing a range of different control and monitoring systems for both ‘on road’ and ‘off

road’ vehicles.

Figure 11: A possible architecture for BMS unit for use on on-road and off-road vehicles.

Vehicle motors

MCU-A

MCU-B

eWDC

Co

nta

cto

rs

Battery units

CAN link to Central Vehicle Control unit

‘enter charge mode’; ‘enter run mode’; ‘open contactors’

TemperatureVoltage

…

FS-A

FS-B

FS-WDC


8. Medical HMI (IEC 60601, IEC 62304, IEC 61508)


Radiotherapy is commonly used to treat forms of cancer by means of high-energy radiation.

The focus in this example will be on external radiotherapy, carried out using what is known as a linear

accelerator (LINAC). A LINAC is designed to focus high-energy radiation beams onto a defined area of the

patient’s body. A typical treatment programme will involve use of the LINAC daily over a period of days or

weeks.

This design example is concerned with the development of the control system for a LINAC.

Our key design requirement is to ensure that the patient does not receive an overdose of radiation.


The key international standard in this area is IEC 60601-2-13.

A new sub-clause (201.10.1.2.101.1.5c) – added in 2014 – requires that the consistency, correctness and

completeness of the data set used by the radiotherapy equipment shall be checked by the equipment

before it can be accepted for irradiation: in the case of failure of the consistency, correctness or

completeness of the data set being loaded, irradiation shall not be allowed to commence.4

The outlined design presented in this section is intended to meet this requirement.

Please note that there are a number of other standards that would need to be considered when developing

the radiotherapy machine, including: IEC 60601-1 (the ‘base’ IEC 60601 standard); IEC 62304; and

IEC 61508. The outline design presented here is expected to be able to achieve compliance with these

standards.5

c) System modules

For the purposes of this discussion, it will be assumed that the radiotherapy equipment is made up of the following modules (the model is simplified, but it will be adequate for the purposes of the discussion here):

the LINAC Radiation Source (LINAC-RS); it is assumed that – if this source is disabled – the risk of harm

to the patient or operators is minimal;

the LINAC Controller (LINAC-C): this is responsible for taking (treatment validated) parameters and

controlling the LINAC-RS in the required manner; if it detects a problem, the LINAC-C shall disable the

LINAC-RS;

the two independent Dose Monitoring Systems (DMS 1 and DMS 2); these are required to measure the

radiation dose applied to the patient and compare this with the required treatment parameters; if

either DMS detects a problem, it shall disable the LINAC-RS;

the Treatment Control Panel (TCP); this is responsible for taking the required treatment parameters

from the operator and checking them; if the parameters are found to be acceptable, these shall be

passed on to the LINAC-C, DMS-1 and DMS-2 (and confirmation from each unit that it has received

these parameters shall be obtained); if the parameters are not found to be acceptable, the TCP shall

disable the LINAC-RS and shall instruct the LINAC-C and DMS-1 and DMS-2 to disable the LINAC-RS too.

3 IEC 60601-2-1: 2009 / AMD1: 2014: Medical electrical equipment: Part 2-1: Particular requirements for the basic

safety and essential performance of electron accelerators in the range 1 MeV to 50 MeV. 4 The text from the standard has been paraphrased here. Please refer to IEC 60601-2-1 for full details and context. 5 Further information about these standards can be found on the SafeTTy Systems website:

https://www.safetty.net/technology/tt-standards

https://www.safetty.net/technology/tt-standards


Figure 12: Our proposed implementation using two DuplicaTTor PLATFORMs in an I-O configuration.

d) Outline designs for the TCP and LINAC-C modules

Figure 12 illustrates how the TCP and LINAC-C modules might be implemented: each module is based on a

DDS-0405-EC.6

The key to this architecture is the separation of the input and output processing (in each module), in order

to provide confidence that: [i] the input data are sensible (for example, within an expected range); and

[ii] the data supplied to one MCU have been confirmed via a second MCU.

For example, consider the intended operation of the TCP module. MCU-A is responsible for controlling the

display of data on the Console Display. The data displayed may appear as a simple text display, or may

appear on a GUI (this makes no difference to the core operation). MCU-B is responsible for obtaining data

from the user. The inputs could come from a touch screen, or any form of keyboard. The only requirement

is that the input device is independent of the Console Display.

The end result is a ‘conversation’ of the form that is summarised in this simplified example:

MCU-A displays: “Enter the required treatment duration (in seconds):”

MCU-A requests an operator input representing the required treatment from MCU-B.

Assume that a value of 5 seconds is entered by the operator via MCU-B.

MCU-B performs a ‘sanity check’ on this value before passing it to MCU-A (if the check is passed).

MCU-A displays: “Please confirm that the required treatment duration is 5 seconds”

MCU-A requests an operator confirmation from MCU-B.

Assume that an input ‘Yes’ is entered by the operator via MCU-B.

MCU-B performs a ‘sanity check’ on this value before passing it to MCU-A (if the check is passed).

MCU-A can then pass this confirmed value to the LINAC-C, DMS 1 and DMS 2.

A similar cross-check then follows on each of these components.

Overall, this cannot guarantee that correct inputs are provided by the operator, but it does reduce the

opportunities for working with incorrect data within the machine itself.

e) Related design examples

This type of ‘confirmed input’ architecture has applications in many other sectors in which machinery or

other devices are controlled by means of parameters that are provided by an operator via some form of

HMI. Examples include: control rooms for power plants; smaller industrial machines (such as lathes);

6 Please note that the DMS units could also be implemented in this way.

Console Display

HMI

LINAC power supply

LINAC-RS

LINAC-CMCU B

LINAC-C

LINAC-CMCU A

TCPMCU A

TCP

TCPMCU B

DMS 1

DMS 2

To DMS 1

To DMS 2


medical equipment; control rooms for rail and other public transport systems; air traffic control systems;

and space systems.

9. Household control (IEC 60730, IEC 60335)


This design example considers a controller for a domestic, gas-powered, ‘combination’ boiler unit (Figure

13). This product is intended to serve two purposes: [i] it heats water that comes from a (cold) mains

supply ‘on demand’ (that is, for example, when a tap is opened over a kitchen sink); and [ii] it heats the

house by pumping warm water around a network of interconnected radiators.

The key safety challenges arise from the fact that the boiler is supplied by (mains) gas and is often required

to operate unattended (even in situations when heating is scheduled to go on when the house is empty).

There is the possibility that an explosion could occur if the boiler does not operate correctly, with the

corresponding risk of loss of life and / or serious injury.


Manufacturers of a domestic boiler system need to comply with various international safety standards,

including IEC 60335-1 and IEC 60730-1.

A key challenge is presented by Clause 19 in IEC 60335-1. This clause requires that electronic circuits must

be designed and applied in such a way that a fault condition will not render the appliance unsafe with

regard to electric shock, fire hazard, mechanical hazard or dangerous malfunction.

The effort required to demonstrate compliance with this core clause (and the standard as a whole) depends

on the class of equipment being developed: the options are Class A, Class B or Class C.

Class A control functions are not intended to be relied upon for the safety of the application (IEC 60730,

H.2.22.1).

Class B control functions are intended to prevent an appliance from entering an unsafe state; however,

failure of the control function will not lead directly to a hazardous situation (IEC 60730, H.2.22.2).

Class C control functions are intended to prevent special hazards such as explosion; failure of such

functions could directly cause a hazard in the appliance (IEC 60730, H.2.22.3).

Figure 13: An overview of the combination-boiler system.

Main HMI(Set heating schedule and

room temperature)Wireless 433 MHz.

Water to radiators

DHW supply

Water fromradiators


Figure 14: An overview of the proposed control system for the boiler. In the figure ‘DHW’ refers to ‘Domestic Hot Water’ (supplied via bath taps and a shower, for example).

c) Outline design

The boiler control system (BCS) considered in this example would fall into IEC 60730 Class C.

IEC 60730 lists a dual-channel (homogenous) architecture, with comparison, as one way of meeting Class C

requirements (see IEC 60730, H.2.16.3). Class C designs are also required to have at least two switching

elements to directly de-energise safety-related outputs (see IEC 60730, 11.3.5.2).

The DDS-0405-EC provides an effective foundation for products that need to meet Class C requirements

(Figure 14).

In this design it is assumed that the main HMI unit has a wireless connection to the BCS.

The fail-safe state identified for the boiler involves removing power from the BCS. This – it is assumed – will

also disable the main gas valve that is connected to the unit. Periodic tests of this gas valve would be

carried out during normal operation of the system (and every time the heating system was activated or

there was a demand for hot water).

[Gas valve power supply]

Main gas valve

MCU-A

MCU-B

eWDC

FS-A

FS-B

FS-WDC

Main HMI(Set heating schedule and

room temperature)Wireless 433 MHz.

Water to radiators

DHW supply

Water fromradiators

Divertor valve; Fan; Water pressure sensor;Pump; Flow thermistor;Heat exchanger thermistor …


10. Aerospace control (DO-178C)

a) Introduction

As noted in Section 4 (in the caption to Table 1), the DDS-0405-EC is primarily designed as a means of facilitating the development of embedded systems that need to achieve compliance with a range of international safety standards at a level up to ‘SIL 3’ / ‘ASIL D’ / ‘Class C’.

There is a level above this: specifically, ‘Design Assurance Level’ A (DAL A, DO-178C) / IEC 61508 ‘SIL 4’ requirements are the most challenging that designers have to meet when developing safety-critical systems at the present time: for example, see Table 2.

While many designs at ‘DAL A’ (and equivalent) levels will employ dual processors, there is typically an even greater emphasis on design diversity at this level. This can often mean that a heterogeneous design is employed (based on two different MCUs) with the aim of reducing the impact of any residual design errors in the system (both hardware design errors and software design errors).

The DDS-0405-EC supports a homogeneous design (based on two identical MCUs). Nonetheless, it can still be used for initial prototyping of ‘DAL A’ / ‘SIL 4’ designs (and SafeTTy Systems Ltd can provide a custom heterogeneous design to match the project requirements, if required – see Section 12).

Table 2: Design Assurance Levels (adapted from DO-178C).

Level A Catastrophic Failure would prevent continued safe flight and landing.

Level B Hazardous / Severe-Major

Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes a small number of serious or fatal injuries among the occupants of the aircraft.

Level C Major Failure is significant, but has a lower impact than a Hazardous failure (for example, leads to passenger discomfort rather than injuries).

Level D Minor Failure is noticeable, but has a lower impact than a Major failure (for example, causing passenger inconvenience or a flight plan change)

Level E No effect Failure has no impact on safety, aircraft operation, or crew workload.


Figure 15: Rolls Royce Trent 500 turbofan engine.

b) Design example

As an example of the type of ‘DAL A’ design that can be prototyped using the DDS-0405, the development of a controller for a gas-turbine engine for use in a passenger aircraft will be considered.

Figure 15 shows a Rolls Royce Trent 500 turbofan engine. Versions of this engine are used (for example) on Airbus A340 aircraft.

The Trent 500 can generate up to 270,000 Newtons (60,000 lbs) of thrust. Control of the thrust level is provided by means of what is called a FADEC (Full Authority Digital Engine Control) unit. The FADEC unit can be seen as the black box on the top right of the engine in Figure 15.

In this example it is assumed that the aim is to prototype this FADEC.

The FADEC would need to meet DAL A requirements.

The DDS-0405 may provide an appropriate starting point for the prototyping of the primary control unit in this system (Figure 16).

Please note that (even) this heterogeneous architecture is likely to require some form of electrical or mechanical ‘fail safe’ mechanism (that will operate if the Primary Control Unit fails to operate – or fails to shut down - as required).

Further consideration is given to forms of ‘backup’ units in Section 11.

Figure 16: Prototyping the primary control system for a gas-turbine jet engine.

MCU-A

Primary Control Unit

MCU-B

Secondary control

unit


11. The need for ‘Limp home’ and backup systems

In Section 4, the typical system and safety requirements that can be met using an adapted version of the

DDS-0405-EC were summarised (informally) as follows: ‘do what you are required to do or shut down’.

In many systems – such as the robot controller considered in Section 5 – this may be appropriate

behaviour.

Other systems cannot simply be shut down, because this may leave users of the system, people in the

vicinity or other animals at risk (for example, see Figure 17): instead some way of ‘limping home’ is required

in situations where it is not possible to meet all of the system requirements.

The DDS-0405-EC can be used as a component in systems that require ‘Limp Home’, ‘Backup’ or other

forms of recovery behaviour but it does not provide (and does not attempt to provide) a complete

framework for the implementation of such systems.

If you wish to incorporate a DDS-0405-EC in a system that requires ‘Limp Home’, ‘Backup’ or other forms of

recovery behaviour, it is recommended that you discuss this with the design team at SafeTTy Systems.

Please visit the company website for contact information: https://www.safetty.net/contact

12. Working with alternative hardware targets

As noted in Section 1, the DDS-0405-EC can be used ‘out of the box’ with the DEB-0405 (see D4 and D5).

The DEB-0405 incorporates two STM32F405 microcontrollers (MCUs).

The DEB-0405 is designed to support design evaluation and prototyping only. For the final product, some

form of custom PCB will be required. This PCB may – for example – be required to provide additional

hardware features and / or to support a different MCU family.

To support your development process, SafeTTy Systems Ltd can provide fully-customised PCB designs (and

matching DDS software frameworks) based on any available MCU hardware (including heterogeneous

platforms – see Section 10).

Please contact your SafeTTy Systems representative for details, or visit the company website for contact

information: https://www.safetty.net/contact

13. Conclusions

This document has introduced the DuplicaTTor® Design Suite ‘DDS-0405’, and outlined some possible

application areas for this product.

Links to information about the use of the DDS-0405 can be found in the ‘Related Documents’ list on p.5.

https://www.safetty.net/contact

https://www.safetty.net/contact


Figure 17: One scenario that is likely to require at least ‘limp home’ functionality.