Autonomica: Ontological Modeling and Analysis of Autonomous Systems
Maged Elaasar, PhD (elaasar@jpl.nasa.gov)
Jet Propulsion Laboratory
California Institute of Technology
Copyright 2023 California Institute of Technology. Government sponsorship acknowledged
Autonomica Team @
2
Maged Elaasar (PI)
Klaus Havelund
Saptarshi Bandyopadhyay
Martin Feather
Alberto Candela
Nicolas Rouquette
Autonomica: Model-based Testing of Autonomy
3
4. Physical Simulation
(Physical Phenomena)
measurements
commands
disturbances
sim telemetry
1. Test Engine
(Directs simulations to search for tests that challenge the system)
task networks
system telemetry
<<MODEL>>
Regression Tests
<<MODEL>>
System Model
design insights
found
tests
DS
RS
2. Deliberative Subsystem
(Planning and Execution)
3. Reactive Subsystem
(Estimation and Control)
goals
estimates
operational scenarios
System Implementation
Autonomica: Case Study
4
Autonomous Mission to a Small Body
Example Tasks: Final 3h of Approach
5
S/SBObs: Observe Small Body
HTCM: Perform Heating and Trajectory Correction Maneuver
COMM: Communicate with Earth using DSN
Charge Battery Using Solar Array
Autonomy
Tasks
State Analysis (SA) Architecture Pattern
6
Autonomica Formalizes SA Pattern & Method
7
Viewpoints
Queries
State Analysis Modeling Methodology
8
1. Mission Operations
4. System Under Control
(Physical Phenomena)
measurements
commands
task networks
state telemetry
DS
RS
2. Deliberative Subsystem
(Planning and Execution)
3. Reactive Subsystem
(Estimation and Control)
goals
estimates
Control System
1. Model Mission Operations
9
SA vocabulary for modeling mission operation
1.1 Model Timelines
10
Timelines are states and resources that are important to mission operations
1.2 Model Task Templates
11
Task templates are defined with params used to specify pre, maintain, post conditions and impacts on timelines.
DS1:Charge_Battery ($min)
post: RS2:SC_Battery_SOC >= $min
impact: $min, cumulative_rate_pre
1.3 Model Task Networks
12
Task templates are instantiated into Task Instances (with parameter binding and extra conditions) and aggregated into Task Networks.
Example Analysis
13
SELECT ?timeline
WHERE {
?timeline a sa:Timeline .
FILTER NOT EXISTS {
?tasknetwork sa:invokes ?taskInstance .
?taskInstance sa:isInstantiatedBy ?taskTemplate .
?taskTemplate sa:hasImpact ?impact .
?impact analysis:characterizes ?timeline .
}
}
The model is complete when each timeline is impacted by some task network.
2. Model Deliberative Subsystem
14
SA vocabulary for modeling deliberative subsystem
2.1 Model Knowledge and Control Goals
15
Specify the knowledge and control goals and which timelines they impact
sa:impacts
2.2 Model Tasks Sending Goals
16
sa:sends
Specify which goals are sent by which task templates
Example Analysis
17
SELECT ?task
WHERE {
?task a sa:Task .
?task sa:hasImpact ?impact .
?impact analysis:characterizes ?timeline .
?task sa:sends ?goal .
FILTER NOT EXISTS {
?goal sa:impacts ?timeline
}
}
The model is well-formed when every task that impacts a timeline sends a goal that also impacts this timeline.
3. Model Reactive Subsystem
18
SA vocabulary for modeling reactive subsystem
3.1 Model State Variables
19
sa:isProjectedFrom
sa:estimates
Define state variables that estimates physical states (in system under control) and projects to timelines (in deliberative subsystem).
3.2 Model Goal Achievers
20
Define goal achievers, which can be estimators (for knowledge goals) or controllers (for control goals) and specify which state variables they consult or update
3.3 Model Measurements and Commands
21
Define which measurements and/or commands that achievers receive/send from/to the system under control
Example Analysis
22
SELECT ?state ?controller
WHERE {
?controller a sa:Controller .
?controller sa:sendsCommandTo/sa:modifies ?state .
FILTER NOT EXISTS {
?state sa:isEstimatedBy/sa:isUpdatedBy ?estimator
}
}
The model is well-formed when every state that is controlled is also estimated.
4. Model System Under Control
23
SA vocabulary for modeling system under control
4.1 Model Physical Objects
24
Model the hardware components in the system under control and other physical objects in its environment
4.2 Model Physical Interfaces
25
Model the sensor and actuator interfaces of hardware components and specify which measurements or commands they send/receive to/from the control system
sa:sendsMeasurement
sa:isCommandReceivedBy
4.3 Model Physical States and Modes
26
For each physical object, model its physical states and (discrete) modes.
4.4 Model State Effects
27
Model how each physical state and mode affects others, are measured by measurements, and are modified by commands
sa:affects
sa:modifies
sa:isMeasuredBy
Example Analysis
28
SELECT ?mode
WHERE {
?mode a sa:PhysicalMode .
FILTER NOT EXISTS {
?mode sa:affects+ ?state .
}
}
The model is well-formed when every mode affects some state
Summary
29