Software and System Health Management with R2U2 · and framework for the real-time system and...

Introduction R2U2 Architecture R2U2: Demo Applications Hardware Variants

Software and System Health

Management with R2U2

Johann Schumann†

†SGT, Inc., NASA Ames Research Center

[email protected]

NASA ARC-Boeing 2019

1 / 33

https://ntrs.nasa.gov/search.jsp?R=20190033108 2020-07-07T19:48:11+00:00Z


Abstract

R2U2 (Realizable, Responsive, Unobtrusive Unit) is a hardware-supported tooland framework for the real-time system and software health management ofcyber-physical systems. R2U2 continuously monitors properties about safety,performance, and security of the vehicle and can perform diagnostic reasoning.E�cient observers for past-time and future-time Metric Temporal Logic,reasoners for Bayesian Networks, and model-based prognostics algorithms aremajor components of R2U2. Their combination makes it possible to designpowerful models for system runtime monitoring, diagnostics, software healthmanagement, prognostics, and security monitoring.The R2U2 monitoring engine is designed for minimal runtime overhead and isavailable as Simulink block or as a software component for integration into theflight software stack, and enables R2U2 to monitor complex cyber-physicalsystems without any instrumentation of the flight software.In this presentation, we give an overview of R2U2 architecture and reasoningalgorithms, present its features, and give a life demo of the tool.

2 / 33


Overview

R1 : start-talk �! ⌃[40,50min]”Last Slide”

R2U2

Responsiveness: respond in “real time”

Realizability: plug-and-play

Unobtrusiveness: do not “mess up” the flight software

Unit

R2U2 is a Run-time monitoring and V&V tool that combines MetricTemporal Logic observers, Bayesian Network reasoners, and model-basedPrognostics for high expressiveness.

3 / 33


Why all the R2U2 Ingredients?

Di↵erent health management approaches focus on specific properties

probabilistic

model

base

d

tempora

l

Boolean Logic (assertions)Limit Checker (cFS), Monitors

Model-Based Diagnostics andMonitoring

HyDETEAMSPrognostics

TemporalTimed Failure PropagationGraph (TFPG)

ProbabilisticBayesian Networks

4 / 33


Why all the R2U2 Ingredients?

Di↵erent health management approaches focus on specific properties

R2U2

model

base

d

tempora

l

Prognostics

probabilistic

Boolean Logic (assertions)Limit Checker (cFS), Monitors

Model-Based Diagnostics andMonitoring

HyDETEAMSPrognostics

TemporalTimed Failure PropagationGraph (TFPG)

ProbabilisticBayesian Networks

Our R2U2 framework provides powerful mechanisms to enable temporal,probabilistic diagnostic models integrating advanced prognostics models.

4 / 33


Overview of the Talk

R2U2 Architecture

Metric Temporal Logic

Bayesian Networks

Prognostics

R2U2 Simulink Integration and Demo

R2U2 for Security Monitoring

R2U2 Hardware Variants

Summary

5 / 33


R2U2 Architecture

UAS R2U2

Netw

ork

Battery

Prognostics

Monitors

MTL

Pro

cessin

g

Sig

na

l

com

pu

ter

Fli

gh

t

Ba

yesia

n

R2U2 as Simulink Block

R2U2 as software app for cFS/cFE Core Flight System

R2U2 on parallel co-processor (Epiphany)

R2U2 as stand-alone software

R2U2 on Field Programmable Gate Array (FPGA)

6 / 33


Ingredient I: Metric Temporal Logic

Future Time Metric Temporal Logic (MTL) reasons about boundedtimelines:

Atomic propositions: p, q

Operators: ¬, ^, _, !, $, �,⇤I , ⌃I , UI , RI

⇤[2,6]p Always[2,6] 0 1 2 3 4 5 6 7 8p p p p p

⌃[2,6]p Eventually[0,7] 0 1 2 3 4 5 6 7 8p

pUq until figures/pUq_timeline.pdf

Past Time: similar with Historically, Once, Since

7 / 33


Observer Pairs

For each future time MTL formula, we create two observers:

asynchronous observers return {T ,F}results are not instantaneousobserver has considerable complexity and needs local memory

synchronous observer returns {T ,F ,maybe} at each timestampresults immediately availableobserver has low complexitythree-valued logic can be useful for reasoning

We do not translate MTL formulas into finite state machines; rather weuse synchronisation queues [TACAS’2014]

8 / 33


Example: Safety Rule

After receiving a command for takeo↵, the UAS must reach an altitudeof 600ft within 60 seconds.

⇤((cmd == takeo↵) ! ⌃[0,60s](alt � 600 ft))

T T

600ftaltitude

60 sec

cmd == takeoff

F

maybe

asynchronous

synchronous

9 / 33


Example: UAS Monitoring I (Past Time)

If the battery current is high for the last 10 seconds, we expect thatduring that time, we have a consecutive climb for at least 3 seconds

⇤[10s](Ibatt > 28A) ! ⌃[10s]⇤[3s](Vz > 5ft/s)

10 / 33


Example: UAS Monitoring II (Past Time)

When in the mode ”guided” or ”auto”, after a change of the targetheading, the NAV heading needs to be aligned within 5 timestamps.Short glitches in the alignment should not count.

(mode == guided _mode == auto) !(⌃[2]heading achieved _ ⌃[3]nav bearing changed)

11 / 33


DEMO: R2U2 Visualizer

The R2U2 Visualizer runs under Matlab and Simulink and enables theinteractive exploration and validation of R2U2 Temporal Formulas.

12 / 33


Ingredient II: Bayesian Reasoning

Our Bayesian Networks contain

unobservable health nodes H

unobservable behavior nodes

observable sensor nodes S

Health

Behavior

Sensor

H_Laseralt

S_Laseralt S_SoC

H_Baroalt

S_Baroalt

U_Climb U_Climb_engine

C_Climb_init

During operation

inputs are clamped at observable S nodes

posteriors of the health nodes H reflect the most likely health statusof the component

E�cient implementation using Arithmetic Circuits

We use SamIam for modeling: http://reasoning.cs.ucla.edu/samiam/

13 / 33

http://reasoning.cs.ucla.edu/samiam/


Example 1: Sensor Monitoring

UAS with Baro, Speed (Pitot), LIDAR, and GPS sensor must fly safelyover mountaineous terrain. Sensor failures must recognized.

2265m

1000m596m

Innsbruck

Austria

Germany

© 2009 GeoBasis-DE/BKG© 2017 DigitalGlobe

© 2016 Google

temp

high buildings

GPS

LIDAR

Pitot

Baro

fog

fog low pressure

clear

H_GPS H_BARO

U_CLIMB

vz_climbgps_satellites_visibleIMU_climb

press_rate_climbabsdiff_alt_gps_rawalt_sign_consistent throttle_climb battery_health

U_ECLIMB

14 / 33


Example 1: Sensor Monitoring: Simulation Results

Baro Failure

alt

[m]

20

60

100 GPS alt

P

0

0.5

1

H_BAROH_GPS

timestamp [x2s]20 40 60 80 100 120

GPS Failure

GPS alt

pre

ss [

mb

]

895900905

H_BAROH_GPS

timestamp [x2s]10 20 30 40 50 60

USE_BARO

USE_GPS

NO_BARO

NO_BARO_inner

IMU_climb

gps_satellites_visible_low

vz_climb

alt_sign_consistent

absdiff_alt_gps_raw_alt_small

press_rate_climb

throttle_climb

15 / 33


Ingredient III: Model-based Prognostics

start-climb �! ⇤[10min]battery-OK

Not Good: valuation only after 10 minutes or ”maybe”

start-climb �! (RUL > 10min)

Good: model-based prognostics. Result available now

R2U2 uses electro-chemical model for LiPo batteries and UKF-based algorithm

16 / 33


Signal Processing

R2U2 generates customized C code for filtering and signal processingfrom a compact specification

FIR low-pass filter of order n

Moving average with window size n

FFT of length n

Rate filter (for scalar or angle)

Linear interpolation

Regular expression for strings

Prognostics

. . . (easy extensible)

17 / 33


DEMO: R2U2 Simulink Integration

18 / 33


Security Monitoring for Autonomous Vehicles

Autonomous vehicles are an easy target for malicious attacks

Multiple attack surfaces via:malicious commands sent to the UAS,compromised flight softwareGPS spoofing

Threat detection and diagnosis has to be performed on-board

R2U2 performs system behavior monitoring and reasoning to detectmalicious attacks

19 / 33


Example: Malicious Commands cause Oscillation

Detect attack via dangerous GCS commands that cause UAS oscillation

-0.5

0

0.5

pitchMAV

0

50

100

150density low freqdensity high freq

FTFTFT

COLOH

timestamp [x200ms]0 2000 4000 6000 8000

FTFT Attackosc1

Attackosc2

received commandschange gains ofcontrol loops

we use FFT to detectoscillations in low OL

and high OH

frequencies

monitoring by:⇤(C ^ ⌃[0,500](⇤[0,200]OH))

⇤(C ^⌃[0,1200](⇤[0,300]OL))

20 / 33


Example: GPS Jamming and Spoofing

Autonomous vehicles heavily rely on GPS for navigationAttack 1: Jamming comms with a powerful transmitterAttack 2: Spoofing: a valid GPS signal is overlaid with an attacksignal corresponding to slightly di↵erent coordinates

The UAS is flying to where the bad guy wants it.Maps c�Google

21 / 33


Experiment: Detection of GPS Spoofing

R2U2 can detect GPS spoofing by monitoring multiple signals of theFSW and correlating GPS, flight path, and inertial navigation.

16.216.316.4

actual latitudedesired latitudestart GPS spoof

0

5

10

EKF offset North

−100

−50

0

EKF offset East

0 1000 2000 3000 4000 5000FTFT

timestamp [x200ms]

R2U

2

SPOOFGPS−NorthSPOOFGPS−Eeast

actual and desiredlatitude

Filtering output of mixedsignals (North)

Filtering output of mixedsignals (East)

Bayesian Network can beused for furtherdisambiguation

22 / 33


Unobtrusive Monitoring

The flight software must not be instrumented or modified. Still (global)variables of interest must be monitored while the software is running.

Fra

me

bu

ffer

R2U2

SuO

EPIPHANY

Lin

ux/A

RM

DMA

DMA

mapping of variables of interest toshared memory bu↵er

special memory regionframe bu↵er

accessible from R2U2 via DirectMemory Access (DMA)

fast hardware synchronization

no modifications or instrumentation of code

minimal changes in timing

23 / 33


Scalability: Parallelization of R2U2

Three levels of parallelization1 Parallel pipeline of

AT: signal preprocessingTL: temporal reasoningBN: Bayesian reasoning

2 Parallel execution of AT filters

3 Parallel evaluation of TL formulas

EPIPHANY

mon

itor

ed

sign

als

R2U2/E

AT T L B N

Di↵erent sets of intermediate registers enable us to run AT, TL, and BNin parallel without having to synchronize the shared data.

24 / 33


R2U2 and the ”V”

RequirementEngineering

System/SWDesign

SoftwareDevelopment

UnitTesting

IntegrationTesting

AcceptanceTesting

Code

3. IKOSStatic code analyzer for C/C++ with low false positive rate

2. CocosimSafety requirement

verification on Simulink models

4. MARGInSValidation testing to

identify unusual behaviors

1. FretSafety requirements

specification

R2U2

R2U2R2U2

25 / 33


Selected Publications

J. Schumann, et.al. R2U2 Manual, 2018.

K. Y. Rozier and J. Schumann. R2U2: Tool Overview RV-CuBES 2017.

P. Moosbrugger, K. Y. Rozier, and J. Schumann. R2U2: Monitoring and Diagnosis of Security Threats for Unmanned

Aerial Systems. Formal Methods in System Design, 2017.

J. Schumann, I. Roychoudhury, and C. Kulkarni: Diagnostic Reasoning using Prognostic Information for Unmanned

Aerial Systems. In PHM-2015, 2015.

J. Schumann, K. Y. Rozier, T. Reinbacher, O. J. Mengshoel, T. Mbaya, and C. Ippolito: Towards Real-time,

On-board, Hardware-supported Sensor and Software Health Management for Unmanned Aerial Systems. IJPHM, 2015.

J. Geist, K. Y. Rozier and J. Schumann: Runtime Observer Pairs and Bayesian Network Reasoners On-board FPGAs:

Flight-Certifiable System Health Management for Embedded Systems In RV 2014, Springer, 2014.

T. Reinbacher and K. Y. Rozier and J. Schumann: Hardware Enabled Unobtrusive Health Monitoring of Real-Time

Systems. In TACAS 2014, Springer, 2014.

A. Srivastava and J. Schumann: Software Health Management: A Necessity for Safety Critical Systems. Innovations in

Systems and Software Engineering, Springer, 9(4):219–233, 2013.

26 / 33


Team

Johannes Geist

Timmy Mbaya

Thomas Reinbacher

Julian Rhein

Kristin Rozier

Johann Schumann

PoC: [email protected] or [email protected]

27 / 33

Software and System Health Management with R2U2 · and framework for the real-time system and...

Documents

Transcript of Software and System Health Management with R2U2 · and framework for the real-time system and...