SoI Real-time, Middleware and Runtime Assurance Groups · 2017-08-12 · Derek Kingston. James...

SoI Real-time, Middleware and Runtime Assurance Groups

03 Aug 2017

Agenda

• Group Description• Group Objectives• Group Accomplishments• Lessons Learned• Recommended Future Directions

Architecture Group 2

Group Description – RTOS/Middleware Members

John Backes

Derek KingstonJames Hamil

James EdmondsonDionisio de Niz

Group Description – Runtime Assurance Members

Aaron FifarekErika HoffmanStanley Bak

James EdmondsonSagar Chaki

Group Objectives – RTOS/Middleware/RTA

• Improve UxAS with quality-of-service• Reduce and mitigate emergent behavior• Provide verifiable, deterministic characteristics to aid in verification and validation• Focus on timing and control improvements

• Formally verify a safety property (collision avoidance) with multi-agent UxAS• Demonstrate mission-focused multi-agent autonomy with safety and

criticality properties• Demonstrate Runtime Assurance Timing Correctness• Demonstrate Runtime Assurance Logical Correctness

Group Accomplishments – RTOS/Middleware/RTA

• Created a GamsService in UxAS (branch: realtime_middleware/gams_service)• GamsService provides both MADARA and GAMS capabilities to the UxAS architecture• Both of these are needed to support the formal verification process called DART

• Created examples of GamsService usage• Simple waypoints• Zone defense• Stigmergy example for spelling AFRL

• Ported the DART process for formal verification to GamsService-enabled applications

• Implemented and Demonstrated Runtime Assurance in Logic and Timing

Group Accomplishments – GamsService (1)

MADARA (Multi-Agent Distributed Adaptive Resource Allocation)

• Provides thread-safe world model• State-based programming model• Developed for multi-agent autonomy• Supports various networking transports

(DDS, UDP, Multicast, Broadcast, 0MQ)• Hundreds of quality-of-service options on

communication, threading, and knowledge/state transfer

• UxAS services can now share state intranode with no message passing

http://madara.sourceforge.net/

Group Accomplishments – GamsService (2)

GAMS (Group Autonomy for Mobile Systems)

• Built on MADARA• Provides portable logic and algorithms• Dozens of mission-focused algorithms for

ISR, asset defense• Standard access to robotic platforms• Scalable to thousands of agents• Hundreds of quality-of-service

parameters, logging features, checkpointing of state, etc.

http://jredmondson.github.io/gams/

Group Accomplishments – GamsService (2)

GAMS (Group Autonomy for Mobile Systems)

• Built on MADARA• Provides portable logic and algorithms• Dozens of mission-focused algorithms for

ISR, asset defense• Standard access to robotic platforms• Scalable to thousands of agents• Hundreds of quality-of-service

parameters, logging features, checkpointing of state, etc.

http://jredmondson.github.io/gams/

Group Accomplishments – GamsService (3)

How UxAS Services Interact with GamsService• Load GamsService and run GAMS algorithms like waypoints, area coverage, zone

defense, spell, etc., usually loaded from KaRL script files (see Backup slides)• Use GamsService::s_knowledgeBase to get or set knowledge• Add non-UxAS transports to GamsService::s_knowledgeBase such as UDP and DDS• Create separate controllers for state-based, deterministic control loops such as shown

in GamsServiceDriver• Examples 10_* - 14_* show usage of GamsService• Additional examples in 20_* - 22_*

Group Accomplishments – GamsService (4)

Example of GamsService (13_GamsService_ZoneDefense)

Group Accomplishments – GamsService (5)

Example of GamsService (14_GamsService_AFRLspell)

Group Accomplishments – GamsService (6)

We also demonstrated these algorithms in the ocean in Portugal (non-UxAS, just GAMS)• Spell algorithm was written in 4-6 hours while in Portugal then example written for UxAS• Collision avoidance is built-in using a double-barrier system (next slides will discuss)• Official SEI distributed autonomy tutorial series is being released within next 2 weeks (free)

https://www.youtube.com/watch?v=N6PfUubaVMY July 10-23, 2017 (NATO REP17 Exercises in Portugal)

Group Accomplishments – DART (1)

• Collision Avoidance for autonomous UAS developed in projects at the SEI• Model Checking Distributed Algorithms (MCDA, 2013-2014)• Verifying Distributed Adaptive Real-Time Systems (DART, 2014-2016)

• Key Ideas:• Mission area (space) is discretized into cubes• Mission duration (time) is discretized into rounds of computation• The protocol ensures that in each round, distinct nodes occupy distinct cubes

• Treats each cube as a resource and implements a distributed mutual exclusion protocol• Assumes a synchronous model of computation (MOC)

• A node starts computing round 𝑖𝑖 only after it receives results of round 𝑖𝑖 − 1 from other nodes• We used a shared variable model of computation implemented via MADARA• The synchronous MOC was implemented by a new “double barrier” algorithm also implemented on top

of MADARA• Sagar Chaki, James R. Edmondson: Model-Driven Verifying Compilation of Synchronous Distributed Applications.

MoDELS 2014: 201-21

Group Accomplishments – DART (2)

• Phase 1: Verification for a finite number of nodes and a finite grid• Protocol was implemented in a DSL called DMPL (developed in the DART project)• An instance of the protocol for 𝑛𝑛 nodes and a 𝑥𝑥 × 𝑦𝑦 × 𝑧𝑧 was sequentialized to a non-deterministic C

program• The collision avoidance property was encoded as a assertion

• The assertion was verified via the bounded software model checker CBMC• Both for a finite number of rounds (via bounded model checking)• And for arbitrary many rounds (by manually synthesizing invariants and proving them to be inductive using CBMC)• Successful verification with 𝑛𝑛 = 10 and a 2-dimensional 20 × 20 grid• Stanley Bak, Sagar Chaki: Verifying cyber-physical systems by combining software model checking with hybrid systems

reachability. EMSOFT 2016: 10:1-10:10

• Phase 2: Verification for arbitrarily many nodes and cubes• Parameterized verification via the “cutoff” method• Cutoff proved to be 2, i.e., if there is no collision with 2 nodes, then there is no collision with arbitrary

many nodes• Note that our phase 1 verification already proved no collision with up to 10 nodes

Group Accomplishments – DART (3)

• Implemented as a UxAS service• src/services/CollisionAvoidanceService.{cpp,hpp}• Relies on GamsService to implement shared variables and synchronous MOC

• Key Ideas• Discretizes map into a 2D grid, all vehicle move at same altitude• Intercepts waypoints generated by WaypointPlanManagerService• Modify waypoints to ensure that vehicle moves to a cell only after it has “locked” it

• Adds loitering after waypoints as needed when locking takes additional time• Modified waypoints sent to the vehicle adaptor service (AMASE in our experiments)

• Implementation was first auto-generated from the DMPL implementation, then manually modified to handle UxAS requirements• Modifications include locking multiple locations and handling cases where the next waypoint is in the same

cell as the current waypoint• Needed because the waypoints in UxAS are more general than what we assumed for DART

Group Accomplishments – DART (4)

• Created two new examples based on 02_Example_WaterwaySearch• 20_Collision Avoidance (manually set waypoints in scenario file)• 22_CollisionAvoidance (intercepts waypoints from WaypointPlanManagerService)

20 22

Group Accomplishments – RTA (1)

• Implemented timing isolation and actuations for services• UxAS is a reactive system that asynchronously fires as fast as possible, whenever

possible, which can cause thrashing and non-determinism• As part of this task, we modified TaskManagerService to control actuation of service

callbacks• Ultimately, this makes callbacks deterministic and enables timing verification and real-

time scheduling with priorities, criticalities, etc.

Group Accomplishments – RTA (2)

Plant

Unverified Controller

𝑠𝑠

�𝛼𝛼

Sensed state

Logical Enforcer:Verified Safe Controller

𝑠𝑠

𝛼𝛼

Logically-vetted actuation

�𝛼𝛼

Group Accomplishments – RTA (3)

Scheduler

High Priority

Med. Priority

Low Priority

𝛼𝛼 𝛼𝛼 𝛼𝛼

𝛼𝛼

𝛼𝛼

𝑠𝑠 𝑠𝑠 𝑠𝑠

𝑠𝑠

𝑠𝑠

Preempted by higher priority task

Does not run until higher priority tasks finish

Preempted by higher priority task

Icons credit: http://www.doublejdesign.co.uk

Group Accomplishments – RTA (4)

Scheduler

Icons credit: http://www.doublejdesign.co.uk

High Priority

Med. Priority

Low Priority

𝛼𝛼 𝛼𝛼

𝛼𝛼

𝛼𝛼

𝑠𝑠 𝑠𝑠

𝑠𝑠

𝑠𝑠

Old sensing, late actuation

Old sensing, late actuation

late actuation

Missed deadlinesMissed deadlinesMissed deadlines

overload

Group Accomplishments – RTA (5)

Icons credit: http://www.doublejdesign.co.uk

Scheduler

Only executed in given periodic time budget

Only executed in given periodic time budget

Only executed in given periodic time budget

Only executed in given periodic time budget

Group Accomplishments – RTA (6)

Icons credit: http://www.doublejdesign.co.uk

Scheduler

Only executed in given periodic time budget

Only executed in given periodic time budget

Only executed in given periodic time budget

Only executed in given periodic time budget

𝑠𝑠 𝛼𝛼 𝛼𝛼𝑠𝑠 𝑠𝑠 𝛼𝛼 Decide if calculated 𝛼𝛼used too old 𝑠𝑠 or not

Prevented from delaying other tasks if

overload

𝛼𝛼∗

Calculate a default safe fast actuation executed “just

before” timing budget expires: kernel informs task

Group Accomplishments – RTA (7)

Assuming No Temporal Problems• Continuous evaluation of waypoints

Evaluate if next waypoint inforbidden region (𝛼𝛼)

With temporal protection• Continuous evaluation of waypoints• If budget overruns:

Issue safe stop (𝛼𝛼∗): loiter Resume evaluation of waypoints

(𝛼𝛼)

Group Accomplishments – RTA (7)

Without temporal enforcement (Default UxAS) With temporal enforcement

Group Accomplishments – RTA (7)

Without temporal enforcement (Default UxAS) With temporal enforcement

Lessons Learned

• The UxAS framework can be augmented to provide more quality-of-service• The UxAS framework has the potential for some types of verification,

provided certain changes are made to the asynchronous nature of the framework

• Real-time guarantees with temporal protection in UxAS is effective BUT the real difference would happen within the vehicle

• Multi-agent examples can be cumbersome to setup in UxAS simulations

Recommended Future Directions (1)

• More quality-of-service inserted into UxAS• More documentation of core processes, especially adding multiple agents to

simulations• More useful logging• State-based programming models• More automated build process for UxAS• More formal verification tool support• Integration of machine learning libraries (preferably with an eye toward

quality-of-service and predictability)

Recommended Future Directions (2)

• Generation scripts for multi-agent examples• More effort made toward trusted computing• More security options (encryption, authentication, etc.)• Secure information flow (making sure the right people get the right

information and declassification is limited appropriately)• Access to real vehicles for real-time property and verification applications• Tutorials for research thrusts

Backup Slides (GamsService Invocation 1)

• Actual code to run spell algorithm ({.prefix} expands to “agent.0”, “agent.1”, “agent.leader”, or whatever you are calling the UAS)

{.prefix}.algorithm = "spell";{.prefix}.algorithm.args.text = "afrl";{.prefix}.algorithm.args.group = "group.spellers";{.prefix}.algorithm.args.origin = [45.3365,-121.0169,700];{.prefix}.algorithm.args.buffer = 500.0;{.prefix}.algorithm.args.width = 1000.0;{.prefix}.algorithm.args.height = 1000.0;

group.spellers.members.size=12;group.spellers.members.0="agent.0";group.spellers.members.1="agent.1";group.spellers.members.2="agent.2";group.spellers.members.3="agent.3";group.spellers.members.4="agent.4";group.spellers.members.5="agent.5";group.spellers.members.6="agent.6";group.spellers.members.7="agent.7";group.spellers.members.8="agent.8";group.spellers.members.9="agent.9";group.spellers.members.10="agent.10";group.spellers.members.11="agent.11";

Backup Slides (GamsService Invocation 2)

• Actual code to run zone defense

{.prefix}.algorithm="zone coverage";{.prefix}.algorithm.args.formation="arc";{.prefix}.algorithm.args.assets="agent.0";{.prefix}.algorithm.args.protectors="group.protectors";{.prefix}.algorithm.args.enemies="agent.1";{.prefix}.algorithm.args.buffer=300.0;{.prefix}.algorithm.args.distance=0.5;

group.protectors.members.size=3;group.protectors.members.0="agent.2";group.protectors.members.1="agent.3";group.protectors.members.2="agent.4";

Backup Slides (GamsService Invocation 3)

• Waypoints algorithm with repeat

{.prefix}.algorithm="waypoints";{.prefix}.algorithm.args.locations.size=4;{.prefix}.algorithm.args.locations.0=[45.336664,-120.980900,700.0];{.prefix}.algorithm.args.locations.1=[45.316684,-120.991100,700.0];{.prefix}.algorithm.args.locations.2=[45.346664,-120.970900,700.0];{.prefix}.algorithm.args.locations.3=[45.316694,-120.991200,700.0];{.prefix}.algorithm.args.repeat=3;

Backup Slides (RTA-Implementation Details)

• Open UxAS (rta branch)• Installation instructions in README_ZSRMV_Installation.md• Modified Waterway example

• Added calls to ZSRMV scheduler• Modified cfgWaterway.xml file with timing parameters for the ZSRMVscheduler• Created a virtual “foe” region

• ZSRMV scheduler• Integrated Scheduling Test in Kernel Module

• Prevents adding a task if the addition makes taskset unschedulable• Library

• With scheduling test using same code based in the kernel module• With JNI Java class to use same code based for schedulability

Backup Slides (RTA – Safe Regions in Enforcement)

State space

𝜙𝜙

𝐶𝐶𝜙𝜙𝑘𝑘

Safe region: 𝜙𝜙 holds (e.g. plane in safe region)

Controllable state

𝑆𝑆

𝛼𝛼∗𝐶𝐶𝜙𝜙1

𝐶𝐶𝜙𝜙2𝐶𝐶𝜙𝜙

𝛼𝛼

�𝛼𝛼Null action

(e.g. infinite loop)

Enforcement action:In controlled region

Control action:Improve safety

�𝛼𝛼

Out of control