SoI Real-time, Middleware and Runtime Assurance Groups. 03 Aug 2017

Transcription

1 SoI Real-time, Middleware and Runtime Assurance Groups 03 Aug 2017

2 Agenda Group Description Group Objectives Group Accomplishments Lessons Learned Recommended Future Directions Architecture Group 2

3 Group Description RTOS/Middleware Members Derek Kingston James Hamil John Backes James Edmondson Dionisio de Niz

4 Group Description Runtime Assurance Members Aaron Fifarek Erika Hoffman Stanley Bak James Edmondson Sagar Chaki

5 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

6 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

7 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

8 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.

9 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.

10 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_*

11 Group Accomplishments GamsService (4) Example of GamsService (13_GamsService_ZoneDefense)

12 Group Accomplishments GamsService (5) Example of GamsService (14_GamsService_AFRLspell)

13 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) July 10-23, 2017 (NATO REP17 Exercises in Portugal)

14 Group Accomplishments DART (1) Collision Avoidance for autonomous UAS developed in projects at the SEI Model Checking Distributed Algorithms (MCDA, ) Verifying Distributed Adaptive Real-Time Systems (DART, ) 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 ii only after it receives results of round ii 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:

15 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 nn nodes and a xx yy zz 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 nn = 10 and a 2-dimensional 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

16 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

17 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

18 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 realtime scheduling with priorities, criticalities, etc.

19 Group Accomplishments RTA (2) Unverified Controller αα Logical Enforcer: Verified Safe αα Controller ss Sensed state ss Plant αα Logically-vetted actuation

20 Group Accomplishments RTA (3) High Priority αα αα αα ss ss ss Scheduler Med. Priority Low Priority ss ss αα αα Icons credit: Preempted by higher priority task Does not run until higher priority tasks finish Preempted by higher priority task

21 Group Accomplishments RTA (4) ss ss αα overload αα Old sensing, late actuation Scheduler High Priority Med. Priority Low Priority ss ss αα αα Old sensing, late actuation late actuation Icons credit: Missed deadlines

22 Group Accomplishments RTA (5) Scheduler Icons credit: Only executed in given periodic time budget

23 Group Accomplishments RTA (6) αα ss αα ss αα ss αα Decide if calculated αα used too old ss or not Scheduler Prevented from delaying other tasks if overload Icons credit: Only executed in given periodic time budget Calculate a default safe fast actuation executed just before timing budget expires: kernel informs task

24 Group Accomplishments RTA (7) Assuming No Temporal Problems Continuous evaluation of waypoints Evaluate if next waypoint in forbidden region (αα) With temporal protection Continuous evaluation of waypoints If budget overruns: Issue safe stop (αα ): loiter Resume evaluation of waypoints (αα)

25 Group Accomplishments RTA (7) Without temporal enforcement (Default UxAS) With temporal enforcement

26 Group Accomplishments RTA (7) Without temporal enforcement (Default UxAS) With temporal enforcement

27 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

28 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)

29 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

30 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 = [ , ,700]; {.prefix}.algorithm.args.buffer = 500.0; {.prefix}.algorithm.args.width = ; {.prefix}.algorithm.args.height = ; 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";

31 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";

32 Backup Slides (GamsService Invocation 3) Waypoints algorithm with repeat {.prefix}.algorithm="waypoints"; {.prefix}.algorithm.args.locations.size=4; {.prefix}.algorithm.args.locations.0=[ , ,700.0]; {.prefix}.algorithm.args.locations.1=[ , ,700.0]; {.prefix}.algorithm.args.locations.2=[ , ,700.0]; {.prefix}.algorithm.args.locations.3=[ , ,700.0]; {.prefix}.algorithm.args.repeat=3;

33 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

34 Backup Slides (RTA Safe Regions in Enforcement) Out of control Null action (e.g. infinite loop) αα αα State space SS Control action: Improve safety Safe region: φφ holds (e.g. plane in safe region) αα φφ Controllable state CC φφ kk CC φφ 2 CC φφ 1 CC φφ αα Enforcement action: In controlled region