Download - R&D Project Using SPARK & Ada: OpenUxAS - Amazon S3

R&D Project Using SPARK & Ada:OpenUxASM. Anthony AielloOctober 3rd, 2019

SPARK & Ada Do Autonomy!

M. Anthony AielloOct 3rd, 2019

AdaCore R&D?

Accelerate the development of new tools & technologies (e.g., SSI!)

Develop use cases and examples that we can share with the community

AdaCore R&D?

Accelerate the development of new tools & technologies (e.g., SSI!)

Develop use cases and examples that we can share with the community

Our work on OpenUxAS

What is OpenUxAS?

An Open Research Platform from AFRL: the US Air Force Research Laboratory

Current UAV Operations

Currently, multiple people operate a single UAV

• pilot

• sensor operator(s)

• supervisors to oversee & coordinate

source: nasa.gov

Future UAV Operations

One operator + autonomy software control multiple UAVs


Flexible Task AssignmentOperator: marks mission objectives &

keep-out zones


Flexible Task AssignmentFlexible Task AssignmentOperator: marks mission objectives &

keep-out zonesAutonomy: plans UAV flight paths &

sensor steering

What is OpenUxAS? — User View

What We DidRewrite the Automation Request Validator Service in Ada and SPARK.

Base Classes• 30 packages• 7,015 lines Ada

LMCP• 202 packages• 32,831 lines Ada

(mostly auto-generated)SPARK• 11 packages• 1,794 lines SPARK

function All_Elements_In (V : Vector; S : Set) return Boolean is

(for all J of V !" S.Contains (J));

function Check_For_Keepout_Zones (Id : Int64; Operating_Regions: Operating_Region_Maps; KeepOut_Zones : Int64_Set) return Booleanis (All_Elements_In (Get_KeepOutAreas (Element (Operating_Regions, Id).Content), KeepOut_Zones));

All keep-out areas must be defined in the operating region.

The full property contains 10 predicates and is 79 lines long. The validation procedure is 471 lines long. Proved Correct

What is OpenUxAS?

in pixels. Then we define gsd as

gsd = max

✓dw

rh,dl � dt

rv

◆.

Note that if we fix the UAV’s altitude and the sensor’s fieldof view, gsd depends only on gimbal elevation ✓g . Alsonote that smaller values of gsd correspond to more detailedimages, and gsd is smallest when ✓g = 90�. However,smaller values for gsd are not always desirable, e.g. if theUAV is flying quickly and we want a target to remain inthe sensor footprint longer. For most tasks, we then select atarget value for gsd and set the gimbal elevation ✓g to thevalue that achieves it. If the target value cannot be achieved,✓g is set to 90�.

III. TASKSEach of the automated tasks we describe in this section

plans waypoint-based paths and sensor steering commandsaccording to the task’s type and the value of its customizableparameters. For some tasks, the resulting task path is simplya starting configuration ⌫s and ending configuration ⌫e, withwaypoints placed according to the time-optimal Dubins pathbetween them. For other tasks, the task path is decom-posed into a sequence of starting and ending configurations(⌫s(1), ⌫e(1)), . . . (⌫s(n), ⌫e(n)) that are then connected byDubins paths. For yet other tasks, the task path is computedbased on a function or more complicated algorithm thatdoes not explicitly make use of Dubins paths but returnsa task path that is approximately flyable. In such a case, theUAV’s autopilot will make adjustments as it flies betweenwaypoints, and there may be some deviations between theplanned task path and the actual path flown by the UAV.For sensor steering, some tasks use a single fixed sensororientation throughout, while others require re-positioningthe sensor at certain points on the task path.

The following sections describe planning approaches andparameters for five tasks: Point Inspect, Line Search, Area

Search, Spiral Search, and Sector Search. Note that whileeach task has its own unique parameters, all tasks havea parameter for desired gsd. This sets the sensor gimbalelevation angle ✓g as described in Section II-C.

A. Point Inspect

The Point Inspect task is motivated by the need to image atarget at a known location, possibly from a particular angle ofapproach and standoff distance. Parameters for this task aregiven in Table I. As shown in Figure 3, for a specified pointp, this task is by default configured to start and end with thecenter of the leading and trailing edge of the sensor footprinton p. The angle of approach � is then chosen from a set ofdiscrete angles about p such that the path from the previoustask ending configuration ⌫̄e is minimized. The starting andending configurations ⌫s = (ps, �s) and ⌫e = (pe, �e) arethen computed according to

ps = p + (dl cos(�), dl sin(�), zp) (2)pe = p + (dt cos(�), dt sin(�), zp)

�s = �e = � + 180�.

It should be noted that when searching over the discrete setof angles, we can also apply other metrics for selecting �,e.g. to include a hard constraint for avoiding no-fly zones orto optimize some metric other than distance.

TABLE IPARAMETERS FOR THE POINT INSPECT TASK

Name Description

Point p Point to inspect.Approachangle range(�c, �r)

Range of allowable angles of approach top measured clockwise from inertial North,with �s = �e 2

⇣ ��c ± �r

2

�+ 180�

⌘.

Default = null.Standoffdistance s

Distance from which to approach p. De-fault = dl.

⌫̄e ⌫s

⌫e

p

dt

dl

dt

dl

� = 225�

-1000

-500

0

500

0 1000 2000 3000

positionnorth

(m)

position east (m)

Fig. 3. A Point Inspect task on point p. Since no angle of approach rangeis specified, a search is performed over a discrete set of angles about p, andangle of approach � is chosen to minimize the path.

⌫̄e

⌫s

⌫e

pdt

s

�c = 0�

�c +�r

2�c � �r

2

dt

dl

-1000

-500

0

500

0 1000 2000 3000

positionnorth

(m)

position east (m)

Fig. 4. A Point Inspect task on point p when an angle of approach range(�c,�r) and standoff distance s are specified.

If a particular view angle on a target at p is desired,the user can specify a range of approach angles throughparameters �c and �r. The task will then use the value� 2 [�c± �r

2 ] that minimizes the path or directly set � = �c

if �r = 0�. If the user would like to allow for more time toapproach p or see more of the region leading up to p, the

TABLE IIPARAMETERS FOR THE LINE SEARCH TASK

Name Description

Line l Line to search, defined by points l =l(1), . . . , l(n).

View angles � List of allowable view angles � =�(1), . . . ,�(n). Default = 0�.

Inertial angleflag b

If b = true, interpret view anglesas placing waypoints relative to line lat distance dc and angle � measuredclockwise from inertial North; other-wise, use as the gimbal azimuth g .Default = true.

C. Area Search

The Area Search task is motivated by the need to imageentire regions, possibly using a particular sweep angle andafter visiting a particular point first. The task parametersare given in Table III. The area a is described by verticesa(1), . . . , a(n), with the option to have the task generatevertices that approximate a circle with a specified radiusand center. By default, the task sweeps the area by creating“lane” segments that run at angle � measured clockwise frominertial North, with � = 0� as the default. The user can alsooptionally specify a Point Inspect task to perform before theArea Search, which can be convenient, e.g. if the area has anassociated station or facility that should be inspected beforethe area is searched. Given values for these parameters, thesteps for computing the search path are as follows:

1) If a Point Inspect task is requested, compute thestarting and ending configurations ⌫s(p) and ⌫e(p)as in Section III-A. When computing the subsequentArea Search, ⌫e(p) is then taken as the previous task’sending configuration.

2) Form the convex hull a0 of the polygon a. If a isalready convex, a0 = a.

3) Rotate a0 about its center by ��.4) Find the westernmost point ywa0 of the polygon de-

scribed by a0, and set the starting and ending y-coordinate for the first search lane to y(1) = ywa0 +↵dw2 . At y = y(1), find the southernmost and north-

ernmost points xsa0 and xna0 of a0, and account forthe sensor footprint at the start and end of the laneby setting xs(1) = xsa0 � dl and xe(1) = xna0 � dt.The starting and ending configurations for the first laneare then ⌫s(1) = ((xs(1), y(1), zp), 0�) and ⌫e(1) =((xe(1), y(1), zp), 0�).

5) For each subsequent lane i > 1, set y(i) = y(i �1) + ↵dw. At y = y(i), find the northernmost andsouthernmost points xna0 and xsa0 of a0. If i is odd, setxs(i) = xsa0 �dl, xe(i) = xna0 �dt, and �(i) = 0�. Ifi is even, set xs(i) = xna0 +dl, xe(i) = xsa0 +dt, and�(i) = 180�. The starting and ending configurationsfor the lane are then ⌫s(i) = ((xs(i), y(i), zp),�(i))and ⌫e(i) = ((xe(i), y(i), zp),�(i)).

0 500 1,000 1,500 2,000 2,500 3,000 3,500 4,000�5,000

�4,000

�3,000

�2,000

�1,000

0

1,000

position east (m)

postion

north

(m)

dtdl

dw

dl

⌫s(p)

dl

⌫s(1) ⌫s(13)dt ⌫e(p)

dt

⌫e(1)⌫e(13)

↵dw

� = 0�

Fig. 7. An Area Search over a circle with � = 0�, ↵ = .9, ✓g = 60�,and a Point Inspect task.

�1,000 �500 0 500 1,000 1,500 2,000 2,500 3,000 3,500 4,000 4,500 5,000�5,000

�4,500

�4,000

�3,500

�3,000

�2,500

�2,000

�1,500

�1,000

�500

0

500

1,000

position east (m)

postion

north

(m)

dw

dtdl

dl

⌫s(1)

⌫s(15)

⌫e(15)

dt

⌫e(1) ↵dw� = 30�

Fig. 8. An Area Search over the same circle as in Figure 7, but with� = 30�, ↵ = .6, ✓g = 20�, and no Point Inspect task.

6) Repeat Step 5 until y(i) is less than ↵dw2 from the

easternmost point in a0.7) Rotate the search lanes about the center of a0 by �.8) Connect the search lanes with Dubins paths.

Figure 7 shows an example Area Search for a circle when� = 0�, ↵ = .9, ✓g = 60�, and there is a Point Inspecttask. Figure 8 shows an example for the same circle when� = 30�, ↵ = .6, ✓g = 20�, and there is no Point Inspecttask. Comparing Figure 7 and Figure 8, note that because ✓g

is larger in the former, the leading and trailing edges of thesensor footprint are closer to the UAV and as a result, thesearch lanes start and end much closer to the boundary ofthe circle. In the latter, since ↵ is smaller, the search lanesare closer together and as a result, more search lanes arerequired to complete the task.

D. Spiral Search

The Spiral Search task is motivated by the need to searchfor an entity from a last known location. As the namesuggests, the search is performed by following a spiral path

Flexible Task Assignment


(a+b⋅c) || d||

+ d

a

b

∙

c

UxAS Architecture

FABRIC: ZEROMQ, CMASI

LIN

E

POIN

T

ZYRE

: EXT

ERN

AL

VEH

ICLE

ABST

RACT

COO

PERA

TIO

N

ROU

TEPL

ANN

ER

ASSI

GN

MEN

TO

PT

* *

UTILITIES: TIMING, LOGGING, CONVERSIONS, *

SERVICES / TASKS

FRAMEWORK

AREA

OVE

RWAT

CH

PERS

ISTE

NT

ISR

Tasks Process Algebra Task Assignment

• service-oriented • architecture• 67k lines C++ code• custom message set • (LMCP)• ZeroMQ pub/sub

A platform for autonomous cooperative control.

procedure Increment (X : in out Integer)with Global !" null, Depends !" (X !" X), Pre !" X < Integer'Last, Post !" X = X'Old + 1;

procedure Increment (X : in out Integer)is begin X !# X + 1;end Increment;

Learn more: learn.adacore.com

What is SPARK?A programming & specification language with

proof tools.

absence of run-timeerrors

data dependenciesflow dependenciesfunctional contracts

Goal Establish a foundation for platform-wide proofs of functional, safety and security properties.

Practical Application of SPARK to OpenUxASInitial ResultsM. Anthony Aiello

Dr. Claire DrossDr. Patrick Rogers

Dr. Laura HumphreyJames Hamil

What Comes NextExpand Ada and SPARK work to enable platform-wide proofs.

• expand Ada and SPARK rewrite of base classes• formalize additional service contracts• formalize compositional properties of the • architecture• investigate security properties from the system • level to the code level• incorporate SPARK support for ownership • pointers

distribution unlimited; approved for public release; case number 88ABW-2017-1985 supported by the USAF under contract 18-S8401-17-C1

in pixels. Then we define gsd as

gsd = max

✓dw

rh,dl � dt

rv

◆.

Note that if we fix the UAV’s altitude and the sensor’s fieldof view, gsd depends only on gimbal elevation ✓g . Alsonote that smaller values of gsd correspond to more detailedimages, and gsd is smallest when ✓g = 90�. However,smaller values for gsd are not always desirable, e.g. if theUAV is flying quickly and we want a target to remain inthe sensor footprint longer. For most tasks, we then select atarget value for gsd and set the gimbal elevation ✓g to thevalue that achieves it. If the target value cannot be achieved,✓g is set to 90�.

III. TASKSEach of the automated tasks we describe in this section

plans waypoint-based paths and sensor steering commandsaccording to the task’s type and the value of its customizableparameters. For some tasks, the resulting task path is simplya starting configuration ⌫s and ending configuration ⌫e, withwaypoints placed according to the time-optimal Dubins pathbetween them. For other tasks, the task path is decom-posed into a sequence of starting and ending configurations(⌫s(1), ⌫e(1)), . . . (⌫s(n), ⌫e(n)) that are then connected byDubins paths. For yet other tasks, the task path is computedbased on a function or more complicated algorithm thatdoes not explicitly make use of Dubins paths but returnsa task path that is approximately flyable. In such a case, theUAV’s autopilot will make adjustments as it flies betweenwaypoints, and there may be some deviations between theplanned task path and the actual path flown by the UAV.For sensor steering, some tasks use a single fixed sensororientation throughout, while others require re-positioningthe sensor at certain points on the task path.

The following sections describe planning approaches andparameters for five tasks: Point Inspect, Line Search, Area

Search, Spiral Search, and Sector Search. Note that whileeach task has its own unique parameters, all tasks havea parameter for desired gsd. This sets the sensor gimbalelevation angle ✓g as described in Section II-C.

A. Point Inspect

The Point Inspect task is motivated by the need to image atarget at a known location, possibly from a particular angle ofapproach and standoff distance. Parameters for this task aregiven in Table I. As shown in Figure 3, for a specified pointp, this task is by default configured to start and end with thecenter of the leading and trailing edge of the sensor footprinton p. The angle of approach � is then chosen from a set ofdiscrete angles about p such that the path from the previoustask ending configuration ⌫̄e is minimized. The starting andending configurations ⌫s = (ps, �s) and ⌫e = (pe, �e) arethen computed according to

ps = p + (dl cos(�), dl sin(�), zp) (2)pe = p + (dt cos(�), dt sin(�), zp)

�s = �e = � + 180�.

It should be noted that when searching over the discrete setof angles, we can also apply other metrics for selecting �,e.g. to include a hard constraint for avoiding no-fly zones orto optimize some metric other than distance.

TABLE IPARAMETERS FOR THE POINT INSPECT TASK

Name Description

Point p Point to inspect.Approachangle range(�c, �r)

Range of allowable angles of approach top measured clockwise from inertial North,with �s = �e 2

⇣ ��c ± �r

2

�+ 180�

⌘.

Default = null.Standoffdistance s

Distance from which to approach p. De-fault = dl.

⌫̄e ⌫s

⌫e

p

dt

dl

dt

dl

� = 225�

-1000

-500

0

500

0 1000 2000 3000

positionnorth

(m)

position east (m)

Fig. 3. A Point Inspect task on point p. Since no angle of approach rangeis specified, a search is performed over a discrete set of angles about p, andangle of approach � is chosen to minimize the path.

⌫̄e

⌫s

⌫e

pdt

s

�c = 0�

�c +�r

2�c � �r

2

dt

dl

-1000

-500

0

500

0 1000 2000 3000

positionnorth

(m)

position east (m)

Fig. 4. A Point Inspect task on point p when an angle of approach range(�c,�r) and standoff distance s are specified.

If a particular view angle on a target at p is desired,the user can specify a range of approach angles throughparameters �c and �r. The task will then use the value� 2 [�c± �r

2 ] that minimizes the path or directly set � = �c

if �r = 0�. If the user would like to allow for more time toapproach p or see more of the region leading up to p, the

TABLE IIPARAMETERS FOR THE LINE SEARCH TASK

Name Description

Line l Line to search, defined by points l =l(1), . . . , l(n).

View angles � List of allowable view angles � =�(1), . . . ,�(n). Default = 0�.

Inertial angleflag b

If b = true, interpret view anglesas placing waypoints relative to line lat distance dc and angle � measuredclockwise from inertial North; other-wise, use as the gimbal azimuth g .Default = true.

C. Area Search

The Area Search task is motivated by the need to imageentire regions, possibly using a particular sweep angle andafter visiting a particular point first. The task parametersare given in Table III. The area a is described by verticesa(1), . . . , a(n), with the option to have the task generatevertices that approximate a circle with a specified radiusand center. By default, the task sweeps the area by creating“lane” segments that run at angle � measured clockwise frominertial North, with � = 0� as the default. The user can alsooptionally specify a Point Inspect task to perform before theArea Search, which can be convenient, e.g. if the area has anassociated station or facility that should be inspected beforethe area is searched. Given values for these parameters, thesteps for computing the search path are as follows:

1) If a Point Inspect task is requested, compute thestarting and ending configurations ⌫s(p) and ⌫e(p)as in Section III-A. When computing the subsequentArea Search, ⌫e(p) is then taken as the previous task’sending configuration.

2) Form the convex hull a0 of the polygon a. If a isalready convex, a0 = a.

3) Rotate a0 about its center by ��.4) Find the westernmost point ywa0 of the polygon de-

scribed by a0, and set the starting and ending y-coordinate for the first search lane to y(1) = ywa0 +↵dw2 . At y = y(1), find the southernmost and north-

ernmost points xsa0 and xna0 of a0, and account forthe sensor footprint at the start and end of the laneby setting xs(1) = xsa0 � dl and xe(1) = xna0 � dt.The starting and ending configurations for the first laneare then ⌫s(1) = ((xs(1), y(1), zp), 0�) and ⌫e(1) =((xe(1), y(1), zp), 0�).

5) For each subsequent lane i > 1, set y(i) = y(i �1) + ↵dw. At y = y(i), find the northernmost andsouthernmost points xna0 and xsa0 of a0. If i is odd, setxs(i) = xsa0 �dl, xe(i) = xna0 �dt, and �(i) = 0�. Ifi is even, set xs(i) = xna0 +dl, xe(i) = xsa0 +dt, and�(i) = 180�. The starting and ending configurationsfor the lane are then ⌫s(i) = ((xs(i), y(i), zp),�(i))and ⌫e(i) = ((xe(i), y(i), zp),�(i)).

0 500 1,000 1,500 2,000 2,500 3,000 3,500 4,000�5,000

�4,000

�3,000

�2,000

�1,000

0

1,000

position east (m)

postion

north

(m)

dtdl

dw

dl

⌫s(p)

dl

⌫s(1) ⌫s(13)dt ⌫e(p)

dt

⌫e(1)⌫e(13)

↵dw

� = 0�

Fig. 7. An Area Search over a circle with � = 0�, ↵ = .9, ✓g = 60�,and a Point Inspect task.

�1,000 �500 0 500 1,000 1,500 2,000 2,500 3,000 3,500 4,000 4,500 5,000�5,000

�4,500

�4,000

�3,500

�3,000

�2,500

�2,000

�1,500

�1,000

�500

0

500

1,000

position east (m)

postion

north

(m)

dw

dtdl

dl

⌫s(1)

⌫s(15)

⌫e(15)

dt

⌫e(1) ↵dw� = 30�

Fig. 8. An Area Search over the same circle as in Figure 7, but with� = 30�, ↵ = .6, ✓g = 20�, and no Point Inspect task.

6) Repeat Step 5 until y(i) is less than ↵dw2 from the

easternmost point in a0.7) Rotate the search lanes about the center of a0 by �.8) Connect the search lanes with Dubins paths.

Figure 7 shows an example Area Search for a circle when� = 0�, ↵ = .9, ✓g = 60�, and there is a Point Inspecttask. Figure 8 shows an example for the same circle when� = 30�, ↵ = .6, ✓g = 20�, and there is no Point Inspecttask. Comparing Figure 7 and Figure 8, note that because ✓g

is larger in the former, the leading and trailing edges of thesensor footprint are closer to the UAV and as a result, thesearch lanes start and end much closer to the boundary ofthe circle. In the latter, since ↵ is smaller, the search lanesare closer together and as a result, more search lanes arerequired to complete the task.

D. Spiral Search

The Spiral Search task is motivated by the need to searchfor an entity from a last known location. As the namesuggests, the search is performed by following a spiral path



Tasks Process Algebra Task Assignment

Autonomous, Cooperative Control of Multiple Assets

What is OpenUxAS? — Developer View

A Service Oriented Architecture

UxAS Architecture

FABRIC: ZEROMQ, CMASI

LIN

E

POIN

T

ZYRE

: EXT

ERN

AL

VEH

ICLE

ABST

RACT

COO

PERA

TIO

N

ROU

TEPL

ANN

ER

ASSI

GN

MEN

TO

PT

* *

UTILITIES: TIMING, LOGGING, CONVERSIONS, *

SERVICES / TASKS

FRAMEWORK

AREA

OVE

RWAT

CH

PERS

ISTE

NT

ISR

AFRL’s Question

Can We Show Functional Correctness of OpenUxAS?

Why Functional Correctness?

Keep-out zones may represent

• Terrain

• Obstacles

• Mission no-go areas


Keep-Out Zone

Keep-out zones may represent

• Terrain

• Obstacles

• Mission no-go areas

For mission, privacy, or safety reasons, avoid keep-out zones.

Why Functional Correctness?

Planned Flight Path

Keep-Out Zone

OpenUxAS Components

ZeroMQ

Infrastructure linking Services to ZeroMQ

Service Base

Autom

ation Request Validator

Task Manager

Route Aggregator

Route Planner Visibility

Assignm

ent Tree Branch B

ound

Plan Builder

Waypoint M

anager

OpenUxAS Safety-Critical Components

ZeroMQ


Service Base

Autom


Route Aggregator


Plan Builder

Waypoint M

anager

How Was OpenUxAS Originally Built?

ZeroMQ


Service Base

Autom


Route Aggregator


Plan Builder

Waypoint M

anager

C++ 11


Critical Code? In C++ 11?


ZeroMQ


Service Base

Autom


Route Aggregator


Plan Builder

Waypoint M

anager

C++ 11


ZeroMQ


Service Base

Autom


Route Aggregator


Plan Builder

Waypoint M

anager

C++ 11

TaskBase

Point

Line

Area

Overw

atch

∙∙∙

C++ 11

Goal: Critical Components

ZeroMQ


Service Base

Autom


Route Aggregator


Plan Builder

Waypoint M

anager

(Ful

l) A

daSPA

RK

C++ 11

Goal: All Components

ZeroMQ


Service Base

Autom


Task Manager

Route Aggregator


Assignm

ent Tree Branch B

ound

Plan Builder

Waypoint M

anager

(Ful

l) A

daSPA

RK

C++ 11

Goal: All Components in SPARK (and Ada)

ZeroMQ


Service Base

Autom


Task Manager

Route Aggregator


Assignm

ent Tree Branch B

ound

Plan Builder

Waypoint M

anager

(Ful

l) A

daSPA

RK

C++ 11


ZeroMQ


Service Base

Autom


Task Manager

Route Aggregator


Assignm

ent Tree Branch B

ound

Plan Builder

Waypoint M

anager

(Ful

l) A

daSPA

RK

TaskBase

Point

Line

Area

Overw

atch

∙∙∙

SPARK-or-C++ 11

What We Get from SPARK

Stone Use of the Language Subset: Benefit from simply using SPARK


Stone

Bronze

Use of the Language Subset: Benefit from simply using SPARK

Flow Analysis: Not a significant part of our application


Stone

Silver


Absence of Run-Time Exceptions: Ensure OpenUxAS doesn’t shut down from a run-time exception


Stone

Silver

Gold



Functional Correctness: Prove critical functional properties


Stone

Platinum

Silver

Gold




Full Functional Correctness: Not realistic for OpenUxAS


Stone

Silver

Gold

Solid Foundation

Absence of Run-Time Exceptions

Proofs & Checked Documentation of Code

First Step

Autom


(Ful

l) A

daSPA

RK

The Automation Request ValidatorConfiguration Messages

Configuration State

Service Boundary

The Automation Request Validator

Vehicle{ID, data}

Configuration Messages

Configuration State

vehicles[ID]

Service Boundary


Vehicle{ID, data}

Keep-out{ID, data}


Configuration State

vehicles[ID]

keep-outs[ID]

Service Boundary


Vehicle{ID, data}

Keep-out{ID, data}

Task{ID, data}


Configuration State

vehicles[ID]

keep-outs[ID]

tasks[ID à Task]

Service Boundary


Vehicle{ID, data}

Keep-out{ID, data}

Task{ID, data}


Configuration State

Automation Request{ID, [vehicle ID],

[keep-out ID], [task ID]}

vehicles[ID]

keep-outs[ID]

tasks[ID à Task]

Service Boundary

Handle Automation Request


Vehicle{ID, data}

Keep-out{ID, data}

Task{ID, data}


validvehicles?

Configuration State



vehicles[ID]

keep-outs[ID]

tasks[ID à Task]

no

Service Boundary


error


Vehicle{ID, data}

Keep-out{ID, data}

Task{ID, data}


validvehicles?

validkeep-outs?

Configuration State



yes

vehicles[ID]

keep-outs[ID]

tasks[ID à Task]

no no

Service Boundary


error error


Vehicle{ID, data}

Keep-out{ID, data}

Task{ID, data}


validvehicles?

validkeep-outs?

validtasks?

Configuration State



yes yes

vehicles[ID]

keep-outs[ID]

tasks[ID à Task]

no no no

Service Boundary


error error error


Vehicle{ID, data}

Keep-out{ID, data}

Task{ID, data}


validvehicles?

validkeep-outs?

validtasks?

Configuration State



ValidAutomation

RequestTask Assignment

Pipelineyes yes yes

vehicles[ID]

keep-outs[ID]

tasks[ID à Task]

no no no

Service Boundary


error error error

First Step

Autom


(Ful

l) A

daSPA

RK

First Step

ZeroMQ

Necessary Infrastructure linking Services to ZeroMQ

Service Base — Messaging Functionality

Autom


(Ful

l) A

daSPA

RK

To Do This, We Had To

Update LMCP to automatically generate message types in Ada

Rebuild the service base in Ada and bind to ZeroMQ

Develop an Ada-SPARK interface for sharing message data

Formalize requirements for and prove correctness of the service



• 202 Ada Packages• 32,830 lines of (auto-generated) Ada



• 30 Ada Packages• 7,015 lines of Ada



• 11 SPARK Packages• 1,794 lines of SPARK• 10 predicates defining properties;

79 lines of property specification


Additional Objective





Keep the Structure and Code as Close to the C++ as Possible

Facilitated Accuracy in the Translation

The Ada-SPARK Interface


Ada-SPARK Interface

C++• Complex data model• Heavy use of pointers• dynamic dispatch• reduce copying

Message Obj- id- fields

Other Message Obj

o o o

*

*

pointer

pointer

pointer

Ada-SPARK Interface

C++• Complex data model• Heavy use of pointers• dynamic dispatch• reduce copying


Other Message Obj

o o o

*

*

pointer

pointer

pointer


(pointer) Msg Obj (pointer) Msg Obj

(pointer) Msg Obj (pointer) Msg Obj

pointer

Ada-SPARK Interface

• Retain data model• Same use of pointers• dynamic dispatch• reduce copying

Ada


Other Message Obj

o o o

*

*

access

access

access


(access) Msg Obj (access) Msg Obj


access

Ada-SPARK Interface


Ada• Restricted support for

pointers• non-aliasing• not in tagged types

SPARK


Other Message Obj

o o o

*

*

access

access

access




access

Ada-SPARK Interface




SPARK


Other Message Obj

o o o

*

*

access

access

access




access ?

Ada-SPARK Interface




SPARK




access Message Obj- id- fields

Msg Obj Msg Obj

Msg Obj Msg Obj

deep copy & replace pointers

!

Ada-SPARK Interface




SPARK




access Message Obj- id- fields

Msg Obj Msg Obj

Msg Obj Msg Obj

deep copy & replace pointers

!

Greedy & Expensive

Ada-SPARK Interface




SPARK




access

use an adapter

!

Message Object Adapter

Ada-SPARK Interface




SPARK




access

wrap




access

unwrap

Get_ID

Set_ID

Get_Field

Message Object Adapter

Ada-SPARK Interface




SPARK




access

wrap




access

unwrap

Get_ID

Set_ID

Get_Field

Heavy-Weight

Ada-SPARK Interface




SPARK




access

use a private type

!

Information Hiding with Private Types

type SPARK_Obj is private;

function Wrap (X : Obj_Any) return SPARK_Obj with SPARK_Mode ⇒ Off;

function Unwrap (X : SPARK_Obj) return Obj_Any with SPARK_Mode ⇒ Off;

function Deref (X : SPARK_Obj) return Obj’Class;

private

pragma SPARK_Mode (Off);

type SPARK_Obj is new Obj_Any;






private



Wrap (X : Obj_Any) ⇢ (SPARK_Obj (X))

Unwrap (X : SPARK_Obj) ⇢ (Obj_Any (X))






private



Deref (X : SPARK_Obj) ⇢ (X.all)

Ada-SPARK Interface




SPARK




access

wrap

unwrap

DerefSPARK Obj

Ada-SPARK Interface




SPARK




access

wrap

unwrap

DerefSPARK Obj

Lazy & Light-Weight

Proving Correctness


Proving Correctnessvalidator.adbvalidator.ads

• operating regions are valid• keep-in zones are valid• keep-out zones are valid

• check validity of• operating regions• keep-in zones• keep-out zones

• provide meaningful error messages if invalid

proved correct


proved correct

ü Functional Correctness

ü Absence of Run-Time Exceptions


proved correct

And We Found a Bug in the Original C++!

ü Functional Correctness

ü Absence of Run-Time Exceptions

First Step

ZeroMQ



Autom


(Ful

l) A

daSPA

RK

Our OpenUxAS Demo

ZeroMQ


ServiceBase

Autom


Task Manager

Route Aggregator


Assignm

ent Tree Branch B

ound

Plan Builder

Waypoint M

anager

TaskBase

Point

Line

Area

Overw

atch

∙∙∙

C++ 11

Our OpenUxAS Demo

ZeroMQ


ServiceBase

Task Manager

Route Aggregator


Assignm

ent Tree Branch B

ound

Plan Builder

Waypoint M

anager

TaskBase

Point

Line

Area

Overw

atch

∙∙∙

C++ 11

Our OpenUxAS Demo

ZeroMQ


ServiceBase

Task Manager

Route Aggregator


Assignm

ent Tree Branch B

ound

Plan Builder

Waypoint M

anager

TaskBase

Point

Line

Area

Overw

atch

∙∙∙

C++ 11

C++ OpenUxAS Process

Our OpenUxAS Demo

ZeroMQ



Autom


(Ful

l) A

daSPA

RK

Our OpenUxAS Demo

SPARK / Ada OpenUxAS Process

ZeroMQ



Autom


(Ful

l) A

daSPA

RK

Our OpenUxAS Demo

SPARK / Ada OpenUxAS Process

ZeroMQ



Autom


(Ful

l) A

daSPA

RK

ZeroMQ


ServiceBase

Task Manager

Route Aggregator


Assignm

ent Tree Branch B

ound

Plan Builder

Waypoint M

anager

TaskBase

Point

Line

Area

Overw

atch

∙∙∙

C++ 11

C++ OpenUxAS Process

First Step

What’s Next?


ZeroMQ


Service Base

Autom


Task Manager

Route Aggregator


Assignm

ent Tree Branch B

ound

Plan Builder

Waypoint M

anager

(Ful

l) A

daSPA

RK

TaskBase

Point

Line

Area

Overw

atch

∙∙∙

SPARK-or-C++ 11

Next Step: Refactor for Proof

ZeroMQ



Autom


(Ful

l) A

daSPA

RK

Currently as Close to the C++ as Possible

Next Step: Refactor for Proof

ZeroMQ



Autom


(Ful

l) A

daSPA

RK

Refactor to Accelerate and Simplify Proof

github.com/AdaCore/OpenUxAS/tree/ada

Follow Our Progress!

Results

ZeroMQ



Autom


(Ful

l) A

daSPA

RK

• Correctness proofs completed


Stone

Bronze

Platinum

Silver

Gold


Flow Analysis: Not a significant part of our application



Full Functional Correctness: Not realistic for OpenUxAS


Stone

Bronze

Platinum

Silver

Gold

Use of the Language Subset

Flow Analysis

Absence of Run-Time Exceptions

Functional Correctness

Full Functional Correctness

Benefit from simply using SPARK

Not a significant part of our application

Ensure OpenUxAS doesn’t shut down from a run-time exception

Prove critical functional properties

Not realistic for OpenUxAS


proved correct

Peer Reviews

ZeroMQ


ServiceBase

Autom


Task Manager

Route Aggregator


Assignm

ent Tree Branch B

ound

Plan Builder

Waypoint M

anager

TaskBase

Point

Line

Area

Overw

atch

∙∙∙

Peer Reviews

- Contracts can be used in place of (some) information documentation

- GNAT Doc (will) include contracts in generated documentation

- Contracts review can be included as part of certification-related reviews

Peer Reviews

Contracts can be used in place of (some) information documentation

GNAT Doc (will) include contracts in generated documentation



Peer Reviews

Contracts review can be included as part of certification-related reviews

Peer Reviews





Header



• ?• ?