Infrastructure for Critical Adaptive Distributed Embedded Systems - - PowerPoint PPT Presentation

▶
infrastructure for critical adaptive
SMART_READER_LITE
LIVE PREVIEW

Infrastructure for Critical Adaptive Distributed Embedded Systems - - PowerPoint PPT Presentation

Aug 14, 2023 128 likes •669 views

Towards a Self-Reconfigurable Infrastructure for Critical Adaptive Distributed Embedded Systems Alberto Ballesteros Julin Proenza Manuel Barranco Lus Almeida Pere Palmer 3 th of July 2018 Universitat de les Illes Balears Introduction

slide-1
SLIDE 1

Towards a Self-Reconfigurable Infrastructure for Critical Adaptive Distributed Embedded Systems

Alberto Ballesteros Julián Proenza Manuel Barranco Luís Almeida Pere Palmer

3th of July 2018 Universitat de les Illes Balears

slide-2
SLIDE 2

Introduction

Distributed Embedded Systems typically have stringent real-time and dependability requirements. When they have to operate under dynamic environments, they must also be flexible to be able to adapt to the changing operational requirements and conditions.

1 / 50

slide-3
SLIDE 3

Introduction

Adaptive Distributed Embedded Systems (ADES) can rearrange themselves autonomously and dynamically

2 / 50

slide-4
SLIDE 4

Introduction

Adaptive Distributed Embedded Systems (ADES) can rearrange themselves autonomously and dynamically Adaptivity is and interesting feature in terms of:

  • Functionality → Change the behaviour
  • Efficiency → Load the necessary functionalities
  • Dependability → Adaptive fault tolerance

3 / 50

slide-5
SLIDE 5

Introduction

4 / 50

To properly implement an ADES it must be provided with the appropriate architecture and mechanisms, that make it possible to fulfil its real-time, dependability and adaptivity requirements

The DFT4FTT project

slide-6
SLIDE 6

To properly implement an ADES it must be provided with the appropriate architecture and mechanisms, that make it possible to fulfil its real-time, dependability and adaptivity requirements

The DFT4FTT project

Introduction

5 / 50

Flexible Time-Triggered (FTT) communication paradigm

  • Real-time
  • Flexibility

FTT Replicated Star (FTTRS)

  • Reliability
slide-7
SLIDE 7

To properly implement an ADES it must be provided with the appropriate architecture and mechanisms, that make it possible to fulfil its real-time, dependability and adaptivity requirements

The DFT4FTT project

Introduction

6 / 50

Dynamic task allocation

  • Flexibility
  • Real-time

Active replication with majority voting

  • Reliability
slide-8
SLIDE 8

Introduction

At the node level, the DFT4FTT architecture is composed of various components

7 / 50

slide-9
SLIDE 9

At the node level, the DFT4FTT architecture is composed of various components

8 / 50

Introduction

slide-10
SLIDE 10

At the node level, the DFT4FTT architecture is composed of various components

9 / 50

Introduction

slide-11
SLIDE 11

At the node level, the DFT4FTT architecture is composed of various components

10 / 50

Introduction

slide-12
SLIDE 12

At the node level, the DFT4FTT architecture is composed of various components

11 / 50

  • Monitor
  • Detect
  • Configuration

change

Introduction

slide-13
SLIDE 13

Outline

12 / 50

  • 1. The task model
  • 2. The Self-Reconfiguration

2.1 Monitoring Process 2.2 Decision Process 2.3 Configuration Change Process

  • 3. Reconfiguration for Reliability
  • 4. Conclusions and On-going Work
slide-14
SLIDE 14

Outline

13 / 50

  • 1. The task model
  • 2. The Self-Reconfiguration

2.1 Monitoring Process 2.2 Decision Process 2.3 Configuration Change Process

  • 3. Reconfiguration for Reliability
  • 4. Conclusions and On-going Work
slide-15
SLIDE 15

Functionality

14 / 50

Task Model

slide-16
SLIDE 16

Functionality

15 / 50

Task Model

slide-17
SLIDE 17

Functionality → Application

Application: Set of distributed and interconnected tasks that are executed in a sequential or parallel manner

16 / 50

Task Model

slide-18
SLIDE 18

Functionality → Application

Application: Set of distributed and interconnected tasks that are executed in a sequential or parallel manner

Task Model

17 / 50

slide-19
SLIDE 19

Functionality → Application

Application: Set of distributed and interconnected tasks that are executed in a sequential or parallel manner Determine a sequence of task executions and message transmissions that allow to meet the deadlines

  • Critical tasks are replicated
  • Message replicas pro-actively transmitted

Task Model

18 / 50

slide-20
SLIDE 20

Outline

19 / 50

  • 1. The task model
  • 2. The Self-Reconfiguration

2.1 Monitoring Process 2.2 Decision Process 2.3 Configuration Change Process

  • 3. Reconfiguration for Reliability
  • 4. Conclusions and On-going Work
slide-21
SLIDE 21

The Self-Reconfiguration

Introduction

20 / 50

At the node level, the DFT4FTT architecture is composed of various components

slide-22
SLIDE 22

The Self-Reconfiguration

Introduction

21 / 50

At the node level, the DFT4FTT architecture is composed of various components

slide-23
SLIDE 23

The Self-Reconfiguration

Introduction

22 / 50

slide-24
SLIDE 24

Outline

23 / 50

  • 1. The task model
  • 2. The Self-Reconfiguration

2.1 Monitoring Process 2.2 Decision Process 2.3 Configuration Change Process

  • 3. Reconfiguration for Reliability
  • 4. Conclusions and On-going Work
slide-25
SLIDE 25

The Self-Reconfiguration

Introduction

24 / 50

slide-26
SLIDE 26

The Self-Reconfiguration

Monitoring Process

25 / 50

slide-27
SLIDE 27

The Self-Reconfiguration

Monitoring Process

26 / 50

Monitor the environment and the system itself Obtain the system status:

  • Status of the architecture → Port Guardians (PGs)
  • Failure Rate and Bit Error Rate → FR model, PGs and sensors
  • Status of the execution → Messages sent by applications
  • Status of the resources → Amount of application resources
slide-28
SLIDE 28

The Self-Reconfiguration

Monitoring Process

27 / 50

slide-29
SLIDE 29

The Self-Reconfiguration

Monitoring Process

28 / 50

slide-30
SLIDE 30

Outline

29 / 50

  • 1. The task model
  • 2. The Self-Reconfiguration

2.1 Monitoring Process 2.2 Decision Process 2.3 Configuration Change Process

  • 3. Reconfiguration for Reliability
  • 4. Conclusions and On-going Work
slide-31
SLIDE 31

The Self-Reconfiguration

Decision Process

30 / 50

slide-32
SLIDE 32

The Self-Reconfiguration

Decision Process

31 / 50

System requirements List of applications, together with their real-time and reliability requirements, that have to be executed

  • Phase-related applications

Indispensable applications needed to fulfil the functional requirements of a given phase of the mission. Maintained by the KE.

  • On-demand-related applications

Indispensable and non-indispensable applications started as a result

  • f a new functional requirement, not related to the phase of the
  • mission. Maintained by the tasks.
slide-33
SLIDE 33

The Self-Reconfiguration

Decision Process

32 / 50

Knowledge Entity The KE determines when a new phase starts and updates the system requirements accordingly. The KE constantly consults the system state and checks if the conditions associated to any of the phases are met

slide-34
SLIDE 34

The Self-Reconfiguration

Decision Process

33 / 50

Tasks Tasks are the only system modules that know the dynamic

  • perational requirements derived from human

commands or the tasks themselves. Start and stop applications, as well as to modify their real-time and reliability requirements. Dependability issues:

  • Use highly-reliable CN
  • Replicate decision tasks and vote
slide-35
SLIDE 35

The Self-Reconfiguration

Decision Process

34 / 50

slide-36
SLIDE 36

The KE constantly verifies that the system reqs are fulfilled

35 / 50

System state System reqs Fulfilment? Change configuration List of tasks

RT requirements R(t) requirements

  • Faulty CNs
  • Tasks executed
  • Falure rates
  • …

The Self-Reconfiguration

Decision Process

slide-37
SLIDE 37

The Self-Reconfiguration

Decision Process

36 / 50

If the system requirements are not fulfilled, the KE decides on the new configuration to apply Finding a new proper configuration can take a lot of time:

  • Provide asap a good configuration for critical apps
  • Provide asap a good configuration for non-critical apps
  • Provide, while the system is running, a better configuration, i.e. good

and optimal according to some specific policy

  • For instance: energy consumption, network performance, QoS, …
  • System designers specify the relevant policies
  • Score each configuration
slide-38
SLIDE 38

Branch and bound with a greedy algorithm

The Self-Reconfiguration

Decision Process

37 / 50

curr conf

slide-39
SLIDE 39

Branch and bound with a greedy algorithm

The Self-Reconfiguration

Decision Process

38 / 50

curr conf

slide-40
SLIDE 40

Branch and bound with a greedy algorithm

The Self-Reconfiguration

Decision Process

39 / 50

curr conf

slide-41
SLIDE 41

The Self-Reconfiguration

Decision Process

40 / 50

Validate functional requirements

  • Check that all the tasks are in the configuration

Validate non-functional requirements

  • Check that the real-time and reliability requirements are met
slide-42
SLIDE 42

Outline

41 / 50

  • 1. The task model
  • 2. The Self-Reconfiguration

2.1 Monitoring Process 2.2 Decision Process 2.3 Configuration Change Process

  • 3. Reconfiguration for Reliability
  • 4. Conclusions and On-going Work
slide-43
SLIDE 43

The Self-Reconfiguration

Configuration Change Process

42 / 50

slide-44
SLIDE 44

The Self-Reconfiguration

Configuration Change Process

43 / 50

Liberate the computational and communication resources

  • f the applications that are no longer required
  • Take into account the interdependencies
  • Take into account the termination condition

Reserve the computational and communication resources

  • f the new required applications

Triggers the execution of the tasks and the transmission

  • f messages in the appropriate order
slide-45
SLIDE 45

Outline

44 / 50

  • 1. The task model
  • 2. The Self-Reconfiguration

2.1 Monitoring Process 2.2 Decision Process 2.3 Configuration Change Process

  • 3. Reconfiguration for Reliability
  • 4. Conclusions and On-going Work
slide-46
SLIDE 46

The self-reconfiguration capabilities of this infrastructure make it possible to change the set of applications being executed in the system, in response to changes in the system state or in the system requirements

45 / 50

Reconfiguration for Reliability

System state System reqs Fulfilment? Change configuration List of tasks

RT requirements R(t) requirements

  • Faulty CNs
  • Tasks executed
  • Falure rates
  • …
slide-47
SLIDE 47

Efficient use of the resources

Redundancy is a typical mechanism used to tolerate faults

  • Is expensive
  • Static redundancy suffers from redundancy attrition

The level of task replication is managed automatically

46 / 50

Reconfiguration for Reliability

slide-48
SLIDE 48

Recovering of tasks

Reallocate the tasks being executed in one CN to another, when the first one suffers a permanent failure. Non-critical tasks

  • The service is restored after some downtime

Critical (replicated) tasks

  • We have redundancy preservation
  • Equivalent to N-Modular Redundancy scheme with spares

47 / 50

Reconfiguration for Reliability

slide-49
SLIDE 49

Outline

48 / 50

  • 1. The task model
  • 2. The Self-Reconfiguration

2.1 Monitoring Process 2.2 Decision Process 2.3 Configuration Change Process

  • 3. Reconfiguration for Reliability
  • 4. Conclusions and On-going Work
slide-50
SLIDE 50

We described the on-going work we are carrying out to construct a self-reconfigurable infrastructure for systems with real-time, reliability and adaptivity requirements. It allows to dynamically modify the allocation of tasks in response to a changes in the system requirements or in the system state.

  • Real-time requirements
  • Reliability requirements

This is particularly interesting for systems that use redundancy

  • Efficient use of the resources
  • Better recovering

49 / 50

Conclusions

slide-51
SLIDE 51
  • Replicate the Node Manager
  • Characterize the self-reconfiguration time
  • Detect the need for reconfiguration
  • Determine a valid new configuration
  • Apply said configuration
  • Construct a prototype to prove its feasibility
  • Evaluate the feasibility of dynamically changing the

replication scheme

50 / 50

On-going Work

slide-52
SLIDE 52

Towards a Self-Reconfigurable Infrastructure for Critical Adaptive Distributed Embedded Systems

Alberto Ballesteros Julián Proenza Manuel Barranco Luís Almeida Pere Palmer

3th of July 2018 Universitat de les Illes Balears