EnergyShield: Provably-Safe Offloading of Neural Network Controllers for
  Energy Efficiency
To mitigate the high energy demand of Neural Network (NN) based Autonomous
Driving Systems (ADSs), we consider the problem of offloading NN controllers
from the ADS to nearby edge-computing infrastructure, but in such a way that
formal vehicle safety properties are guaranteed. In particular, we propose the
EnergyShield framework, which repurposes a controller ''shield'' as a low-power
runtime safety monitor for the ADS vehicle. Specifically, the shield in
EnergyShield provides not only safety interventions but also a formal,
state-based quantification of the tolerable edge response time before vehicle
safety is compromised. Using EnergyShield, an ADS can then save energy by
wirelessly offloading NN computations to edge computers, while still
maintaining a formal guarantee of safety until it receives a response
(on-vehicle hardware provides a just-in-time fail safe). To validate the
benefits of EnergyShield, we implemented and tested it in the Carla simulation
environment. Our results show that EnergyShield maintains safe vehicle
operation while providing significant energy savings compared to on-vehicle NN
evaluation: from 24% to 54% less energy across a range of wireless conditions
and edge delays.
Mohanad Odema, James Ferlez, Goli Vaisi, Yasser Shoukry, Mohammad Abdullah Al Faruque
# EnergyShield: Provably-Safe Offloading of Neural Network Controllers for Energy Efficiency

###### Abstract.

To mitigate the high energy demand of Neural Network (NN) based Autonomous Driving Systems (ADSs), we consider the problem of offloading NN controllers from the ADS to nearby edge-computing infrastructure, but in such a way that formal _s_afety properties are guaranteed. In particular, we propose the EnergyShield framework, which repurposes a controller "shield" as a low-power runtime safety monitor for the ADS vehicle. Specifically, the shield in EnergyShield provides not only safety interventions but also a formal, state-based quantification of the tolerable edge response time before vehicle safety is compromised. Using EnergyShield, an ADS can then save energy by wirelessly offloading NN computations to edge computers, while still maintaining a formal guarantee of safety until it receives a response (on-vehicle hardware provides a just-in-time fail safe). To validate the benefits of EnergyShield, we implemented and tested it in the Carla simulation environment. Our results show that EnergyShield maintains safe vehicle operation while providing significant energy savings compared to on-vehicle NN evaluation: from 24% to 54% less energy across a range of wireless conditions and edge delays.

Formal Methods, Vehicular, Edge Computing, Autonomous Vehicles, Provable safety, Offloading, Autonomous Driving Systems +
Footnote †: journal: J. Accepted 2023, May 09-12, 2023, San Antonio, TX

+
Footnote †: journal: J.
In the event that the edge resources don't provide a response within this time, on-board local compute proceeds to evaluate the relevant DNNs before vehicle safety is no longer assured. Further energy savings are obtained by incorporating an estimator to anticipate edge-compute load and wireless network throughput; a more intelligent offloading decision is made by comparing this estimate against the tolerable edge-compute delay provided by the runtime safety monitor - thus preventing offloads that are likely to fail.

The main technical novelty of EnergyShield is its shield-based runtime safety monitor mentioned above. Although controller "shielding" is a well-known methodology to render generic controllers safe, the shielding aspect of EnergyShield contains two important novel contributions of its own: first, in the use of a shield not only to enforce safety but also as a runtime safety monitor to quantify the _time until the system is unsafe_, and second, in the specific design of that runtime monitor with regard to implementation complexity and energy considerations. In the first case, EnergyShield extends existing notions wherein the _current value_ of a (Zeroing-)Barrier Function (ZBF) is used as a runtime monitor to quantify the safety of an agent: in particular, it is novel in EnergyShield to instead use the current value of the ZBF to derive a _sound_ quantification of the _time_ until the agent becomes unsafe. Moreover, EnergyShield implements this quantification in an extremely energy efficient way: i.e., via a small lookup table that requires only a small number of FLOPS to obtain a guaranteed time-until-unsafe. This particular aspect of the runtime safety monitor is also facilitated by a using a particular, but known, ZBF and shield (Gelman et al., 2015) in EnergyShield: these components are both extremely simple, and so implementable using small, energy efficient NNs (Gelman et al., 2015). Together, these design choices ensures that any energy saved by offloading is not subsequently expended in the implementation of EnergyShield itself.

We conclude the paper with a significant sequence of experiments to validate both the safety and energy savings provided by the EnergyShield framework. In particular, we tested EnergyShield in the Carla simulation environment (Gelman et al., 2015) with several Reinforcement Learning (RL)-trained agents. Our experiments showed that EnergyShield entirely eliminated obstacle collisions for the RL agents we considered - i.e. made them safe - while simultaneously reducing NN energy consumption by as much as 54%. Additionally, we showed that EnergyShield has intuitive, safety-conscious offloading behavior: when the ADS is near an obstacle - and hence less safe - EnergyShield's runtime safety monitor effectively forced exclusively on-vehicle NN evaluation; when the ADS was further from an obstacle - and hence more safe - EnergyShield's runtime safety monitor allowed more offloading, and hence more energy savings.

**Related Work:**_Formal Methods for Data-Trained Controllers_. A number of approaches exist to assert the safety of data-trained controllers with formal guarantees; in most, ideas from control theory are used in some way to augment the trained controllers to this end. A good survey of these methods is (Gelman et al., 2015). Examples of this approach include the use of Lyapunov methods (Gelman et al., 2015; Gelman et al., 2015; Gelman et al., 2015), safe model predictive control (Gelman et al., 2015), reachability analysis (Gelman et al., 2015; Gelman et al., 2015; Gelman et al., 2015), barrier certificates (Gelman et al., 2015; Gelman et al., 2015; Gelman et al., 2015; Gelman et al., 2015; Gelman et al., 2015), and online learning of uncertainties (Gelman et al., 2015). Controller "shielding" (Gelman et al., 2015) is another technique that often falls in the barrier function category (Gelman et al., 2015). Another approach tries to verify the formal safety properties of learned controllers using formal verification techniques (e.g., model checking): e.g., through the use of SMT-like solvers (Gelman et al., 2015; Gelman et al., 2015; Gelman et al., 2015) or hybrid-system verification (Gelman et al., 2015; Gelman et al., 2015; Gelman et al., 2015). However, these techniques only assess the safety of a given controller rather than design or train a safe agent.

_Edge Computing for Autonomous Systems_. A number of different edge/cloud offloading schemes have been proposed for ADSs, however none to date has provided formal guarantees. Some have focused on scheduling techniques and network topology to achieve effective offloading (Gelman et al., 2015; Gelman et al., 2015; Gelman et al., 2015; Gelman et al., 2015). Others focused on split and other NN architectures to make offloading more efficient (Gelman et al., 2015; Gelman et al., 2015; Gelman et al., 2015).

## 2. Preliminaries

### Notation

Let \(\mathbb{R}\) denote the real numbers; \(\mathbb{R}^{+}\) the non-negative real numbers; \(\mathbb{N}\) the natural numbers; and \(\mathbb{Z}\) the integers. For a continuous-time signal, \(x(t),t\geq 0\), denote its discrete-time sampled version as \(x[n]\) for some fixed sample period \(T\) (in seconds); i.e. let \(x[n]\triangleq x(n\cdot T)\) for \(n\in\mathbb{Z}\). Let \(\mathbf{1}_{a}:\mathbb{R}\rightarrow\{a\}\) be the constant function with value \(a\); i.e., \(\mathbf{1}_{a}(x)=a\) for all \(x\in\mathbb{R}\) (interpreted as a sequence where necessary). Finally, let \(\hat{x}=f(x,u)\) be a generic control system with \(x\in\mathbb{R}^{n}\) and \(u\in\mathbb{R}^{m}\), and let \(\pi:\mathbb{R}\times\mathbb{R}^{n}\rightarrow\mathbb{R}^{m}\) be a (possibly) time-varying controller. For this system and controller, consider a time \(\tau\geq 0\) and state \(x_{0}\), and denote by \(\xi_{\pi}^{t_{0},x_{0}}:\mathbb{R}^{+}\rightarrow\mathbb{R}^{n}\) the _to_-shifted state evolution of this system under controller \(\pi\) assuming \(x(t_{0})=x_{0}\). Let \(\xi_{\pi}^{t_{0},x_{0}}[n]\) indicate the same, except in discrete-time and with zero-order hold application of \(\pi\). \(\lVert\cdot\rVert\) and \(\lVert\cdot\rVert_{2}\) will denote the max and two-norms on \(\mathbb{R}^{n}\), respectively.

### Kinematic Bicycle Model

Throughout this paper, we will use the kinematic bicycle model (KBM) as the formal dynamical model for our autonomous vehicle (KBM). However, we consider the KBM model in terms of state variables relative to a fixed point in the plane, rather than absolute Cartesian coordinates. That is, the states are the distance to a fixed point, \(\lVert\vec{r}\rVert\), and orientation angle, \(\xi\), of the vehicle with respect to the same. These quantities describe a state-space model:

\[\left(\begin{smallmatrix}\xi\\ \xi\\ \end{smallmatrix}\right)=\left(\begin{smallmatrix}v\cos(\xi-\beta)\\ -\frac{1}{\rho}\sin(\xi-\beta)-\frac{\mu}{\ell_{\rho}}\sin(\beta)\\ a\end{smallmatrix}\right);\quad\beta\triangleq\tan^{-1}(\frac{\ell_{\rho}}{f _{\pi}+\ell_{\rho}}\tan(\delta_{f})) \tag{1}\]

where \(r(t)\) is distance to the origin; \(a\) is the linear acceleration input; \(\delta_{f}\) is the front-wheel steering angle input; and \(\psi+\xi=\tan^{-1}(y/x)\). We note a few special states for convenience: at \(\xi=\pm\pi/2\), the

Figure 2. Obstacle specification and minimum barrier distance as a function of relative vehicle orientation, \(\xi\).
vehicle is oriented tangentially to the obstacle, and at \(\xi=\pi\) or \(0\), the vehicle is pointing directly at or away from the origin, respectively (Figure 2). \(\beta\) is an _invertible function_ of the steering control, \(\delta_{f}\).

We also assume that the KBM has a steering constraint so that \(\delta_{f}\in[-\delta_{f}\max,\delta_{f\max}]\). For simplicity, we will consider \(\beta\) directly as a control variable; this is without loss of generality, for the reason noted above. Thus, \(\beta\) is also constrained: \(\beta\in[-\beta_{\max},\beta_{\max}]\). Finally, we define the state and control vectors for the KBM as: \(\chi\triangleq(\xi,r,\alpha)\) and \(\omega\triangleq(a,\beta)\), where \(\omega\in\Omega_{\text{admis}}\triangleq\mathbb{R}\times[-\beta_{\max},\beta_ {\max}]\), the set of admissible controls. Thus, the dynamics of the KBM are given by \(\dot{\chi}=f_{\text{KBM}}(\chi,\omega)\) with \(f_{\text{KBM}}\) defined according to (1).

### Barrier Functions and Shielding

In the sequel, we will use a controller "shield", which is a methodology for instantaneously correcting the outputs produced by a controller in closed loop; the objective is to make corrections such that the original controller, however it was designed or implemented, becomes safe - hence the "shield" moniker. Specifically, a controller shield is designed around a real-valued function over the state space of interest, called a (Zeroing-) Barrier Function (ZBF). The ZBF directly specifies a set safe states by its sign: states for which the ZBF is nonnegative are taken to be safe. The ZBF in turn indirectly specifies safe controls (as a function of state) in such a way that the sign of the ZBF is invariant along trajectories of the dynamics.

Formally, consider a control system \(\dot{x}=f(x,u)\) in closed loop with a state-feedback controller \(\pi:x\mapsto u\). In this scenario, a feedback controller in closed loop converts the control system into an autonomous one - the autonomous vector field \(f(\cdot,\pi(\cdot))\). In the context of an autonomous system, then, we recall the following definition for a Zeroing-Barrier Function (ZBF):

Definition 1 (Zeroing Barrier Function (ZBF) (Zff, Definition 2)).: _Let \(\dot{x}=f(x,\pi(x))\) be the aforementioned closed-loop, autonomous system with \(x(t)\in\mathbb{R}^{n}\). Also, let \(h:\mathbb{R}^{n}\to\mathbb{R}\), and define \(\mathcal{C}\triangleq\{x\in\mathbb{R}^{n}:h(x)\geq 0\}\). If there exists a locally Lipschitz, extended-class-\(K\) function, \(\alpha\) such that:_

\[\nabla_{x}h(x)\cdot f(x,\pi(x))\geq-\alpha(h(x))\text{ for all }x\in\mathcal{C} \tag{2}\]

_then \(h\) is said to be a **zeroing barrier function (ZBF)**._

Moreover, the conditions for a barrier function above can be translated into a set membership problem for the outputs of such a feedback controller. This is explained in the following corollary.

Proposition 1 ().: _Let \(\dot{x}=f(x,u)\) be a control system that is Lipschitz continuous in both of its arguments on a set \(\mathcal{D}\times\Omega_{\text{admis}}\): furthermore, let \(h:\mathbb{R}^{n}\to\mathbb{R}\) with \(C_{h}\triangleq\{x\in\mathbb{R}^{n}|h(x)\geq 0\}\subseteq\mathcal{D}\), and let \(\alpha\) be a class \(\mathcal{K}\) function. If the set_

\[R_{h,\alpha}(x)\triangleq\{u\in\Omega_{\text{admis}}|\nabla_{x}^{T}h(x)\cdot f (x,u)+\alpha(h(x))\geq 0\} \tag{3}\]

_is non-empty for each \(x\in\mathcal{D}\), and a Lipschitz continuous feedback controller \(\pi:x\mapsto u\) satisfies_

\[\pi(x)\in R_{h,\alpha}(x)\quad\forall x\in\mathcal{D} \tag{4}\]

_then \(C_{h}\) is forward invariant for the closed-loop dynamics \(f(\cdot,\pi(\cdot))\)._

_In particular, if \(\pi\) satisfies (4) and \(x(t)\) is a trajectory of \(\dot{x}=f(x,\pi(x))\) with \(h(x(0))\geq 0\), then \(h(x(t))\geq 0\) for all \(t\geq 0\)._

Proof.: This follows directly from an application of zeroing barrier functions (Zff, Theorem 1). 

Proposition 1 is the foundation for controller shielding: (3) and (4) establish that \(h\) (and associated \(\alpha\)) forms a ZBF for the closed-loop, autonomous dynamics \(f(\cdot,\pi(\cdot))\). Note also that there is no need to distinguish between a closed-loop feedback controller \(\pi\), and a composite of \(\pi\) with a function that _shields_ (or filters) its output based on the current state. Hence, the following definition:

Definition 2 (Controller Shield).: _Let \(\dot{x}=f(x,u)\), \(h\), \(\mathfrak{C}_{h}\), \(\alpha\) and \(\mathcal{D}\times\Omega_{\text{admis}}\) be as in Proposition 1. Then a **controller shield** is a Lipschitz continuous function \(\mathfrak{S}:\mathcal{D}\times\Omega_{\text{admis}}\to\Omega_{\text{admis}}\) such that_

\[\forall(x,u)\in\mathcal{D}\times\Omega_{\text{admis}}.\mathfrak{S}(x,u)\in R_{ h,\alpha}(x). \tag{5}\]

### A Controller Shield for the KBM

In this paper, we will make use of the existing ZBF and controller shield designed for the KBM in (K
signal, \(y\). Further assume that, by virtue of its size, computing an output of \(\mathcal{NN}_{c}\) with on-vehicle hardware consumes significant energy. Thus, it would be advantageous, energy-wise, to _offload_ evaluations of \(\mathcal{NN}_{c}\) to edge computing infrastructure: in other words, wirelessly transmit a particular sensor measurement, \(y\), to off-vehicle edge computers, where the output \(u=\mathcal{NN}_{c}(y)\) is computed and returned to the requesting ADS.

The problem with this approach is largely from a safety point of view. In particular, the controller \(\mathcal{NN}_{c}\) was designed to operate _in real time and in closed-loop_: i.e. the control action at discrete-time sample \(n\) is intended to be computed from the sensor measurement at the _same_ time sample. In the notation of discrete-time signals (see Section 2.1), this means: \(u[n]=\mathcal{NN}_{c}(y[n])\). However, offloading a sensor measurement, \(y[n]\), to the edge entails that the correct output of \(\mathcal{NN}_{c}(y[n])\) will not be back on-vehicle before some non-zero number of samples, say \(\Delta\). Thus, \(\mathcal{NN}_{c}(y[n])\) will not be available at time \(n\) to set \(u[n]=\mathcal{NN}_{c}(y[n])\) as intended; rather, the soon-set possible use of the output \(\mathcal{NN}_{c}(y[n])\) will be at time \(n+\Delta\), or \(u[n+\Delta]=\mathcal{NN}_{c}(y[n])\). This delay creates obvious safety issues, since the state of the vehicle - and hence the correct control to apply - will have changed in the intervening \(\Delta\) time samples. More importantly, even the "correct" control action applied at \(n+\Delta\) may be insufficient to ensure safety: e.g., after \(\Delta\) samples have elapsed, it may be too late to apply adequate evasive steering.

### EnergyShield Structure

If we assume that the ADS itself has enough on-vehicle compute to obtain an output \(\mathcal{NN}_{c}(y[n])\)_in real time_, then this safety problem above becomes one of making an _offloading decision_: ideally one that saves energy without compromising safety. That is, should a particular computation of \(\mathcal{NN}_{c}\) be offloaded to the edge? And how long should the ADS wait for a response so as to ensure the situation is correctable?

The nature of the offloading decision means that EnergyShield must address two essential and intertwined issues in order to ensure safety of the ADS vehicle during offloading. On the one hand, EnergyShield must be able to _correct_ the control actions provided by \(\mathcal{NN}_{c}\) after an offload decision (see explanation above). On the other hand, EnergyShield must limit the duration it waits for each offloading request, so that actions provided by \(\mathcal{NN}_{c}\)_can_ be corrected in the first place; i.e., among all possible offloading delays, \(\Delta\), it is not immediate which may be corrected and which may not (loosely speaking, \(\Delta=\infty\) is one delay that likely cannot be corrected). In this sense, knowing that a particular response-delay, \(\Delta^{\prime}\) is correctable essentially characterizes how to take an offloading decision, since it provides an _expiration on safety_: i.e., proceed to offload, and wait for a response until \(\Delta^{\prime}\) samples have elapsed - at which point resume local evaluation of \(\mathcal{NN}_{c}\).

In particular, EnergyShield has two central components to achieve these ends:

**C1: Controller Shield**. EnergyShield contains a controller shield (see Section 2.3), which ensures that safety is maintained irrespective of offloading-delayed controller outputs; in other words, it corrects unsafe behavior of \(\mathcal{NN}_{c}\) that results from unanticipated (to \(\mathcal{NN}_{c}\)) changes in vehicle state during offloading delays.
**C2: Runtime Safety Monitor**. EnergyShield contains a runtime safety monitor that provides the ADS an upper bound, \(\Delta_{\max}\) (in samples), on how long it should wait for a response to one of its offloading requests to maintain safety, _assuming no updates to the control action in the meantime_; i.e., provided the offload delay is \(\Delta\leq\Delta_{\max}\), then **C1**, the controller shield, can guarantee safe recovery after holding the last control signal update through offload delay period (**C1** may use on-vehicle computation if necessary). _In other words, \(\Delta_{\max}\) specifies and expiration for the safety guarantee provided by_**C1**_using on-vehicle computation._

Naturally, **C1** and **C2** need to be designed together, since their objectives are mutually informed. Indeed, in the specific design of EnergyShield, these components are designed from the same ZBF (defined in Section 2.3): see Section 4 for formal details.

Unfortunately, neither of the components **C1** nor **C2** can operate effectively on the same raw sensor measurements, \(y[n]\), used by the controller; this is especially true given our intention to implement them via ZBFs and controller shields. In particular, both require some (limited) state information about the ADS in order to perform their tasks. Thus, EnergyShield requires a perception/estimator component to provide state information to **C1** and **C2**. Note that we deliberately exclude the design of such an estimator from the EnergyShield framework in order to provide additional flexibility: in particular, since the controller \(\mathcal{NN}_{c}\) may effectively contain an estimator, we wish to allow for estimation to be offloaded, too - provided it is executed locally just-in-time before informing **C1** and **C2** (see Section 3.3). Nevertheless such an estimator is necessary for EnergyShield, so we include it as component:

**C3: State Estimator**. EnergyShield requires (minimal) state estimates be provided as input to **C1** and **C2**. By convention, this estimator will be a NN denoted by \(\mathcal{NN}_{p}:y\mapsto x\). _We assume that \(\mathcal{NN}_{p}\) can be computed by on-vehicle hardware in one sample period._

The interface of **C3** with both **C1** and **C2** makes the latter two components (state-)context aware. _That is, EnergyShield makes context-aware offloading decisions based on the current vehicle state_. Moreover, it is important to note that since the prior control action will be held during offload \(\Delta_{\max}\), the output of **C2**, control in addition to state dependent: that is, **C2** actually produces an output \(\Delta_{\max}(\hat{x},u)\) for (arbitrary) state \(\hat{x}\) and the control \(u\) applied just before offload.

EnergyShield has one further important component, but one that is motivated purely by energy savings with no effect on safety. Crucially the known expiration of safety provided by **C2**, i.e. \(\Delta_{\max}(x)\), affords the opportunity to use additional information in making an offload decision. In particular, an estimate of the anticipated edge response time, \(\hat{\Delta}\), can be used to _forego_ offloads that are unlikely to complete before the expiration of the safety deadline, \(\Delta_{\max}(x)\). For this reason, EnergyShield contains an estimator of edge response time to preemptively skip offloads that are likely to fail:

**C4: Edge-Response Estimator**. EnergyShield specifies that an estimate of the current edge response time, \(\hat{\Delta}\), is provided to inform offloading decisions.
We note, however, that _EnergyShield doesn't specify a particular estimator to be used in this component_: any number of different estimators may be appropriate, and each estimator may lead to different energy profiles depending on its efficacy. Moreover, since \(\hat{\Delta}\) is never used to override \(\Delta_{\max}(x)\), safety is preserved irrespective of the specific estimator used.

The interconnection of the components **C1** through **C4** in EnergyShield is illustrated in Figure 3. Note that component **C3**, the state estimator, is connected to components **C1** and **C2**, the controller shield and safety runtime monitor, respectively. Also note that the output of **C2** provides a signal \(\Delta_{\max}(x)\) to the offloading decision switch; also informing that decision is the estimate of immediate edge-response times provided by component **C4**.

### Semantics of an EnergyShield Offloading Decision

In this subsection, we consider the timeline of a single, hypothetical EnergyShield offloading decision to illustrate the details of the interplay between the components described in Section 3.2. In particular, suppose that an offloading interval has just been completed, and at time index \(n_{0}\) a new offloading decision is to be taken.

We call the time between the initialization of an offloading decision and the time that offloading decision has been resolved an _offloading period_ (the resolution is either by a response from the edge or a fail-over to on-vehicle compute).

_Timeline:_

1. \(n_{0}-1\) _Last time index of previous offload period._
2. Assumption: \(\hat{x}[n_{0}]\pm x[n_{0}-1]=\mathcal{NN}_{p}(y[n_{0}-1])\) is always computed locally in the last sample of the previous offloading period.
3. \(n_{0}\) _Initial time index of new offload period._
4. The first sample of the new offload period inherits a locally computed \(\hat{x}[n_{0}]\) from the previous offloading period.
5. \(\hat{x}[n_{0}]\) is provided to **C1** to correct \(u[n_{0}]\) as calculated by the previous offloading. Let this correct control action be \(\hat{u}[n_{0}]\)
6. Fix control action applied at \(n_{0}\): i.e. \(u_{\text{0-h}}=\hat{u}[n_{0}]\), with \(\hat{u}[n_{0}]\) as calculated above.
7. \(\hat{x}[n_{0}]\) and \(u_{\text{0-h}}\) are provided to **C2**, the runtime safety monitor, to generate \(\Delta_{\max}(\hat{x}[n_{0}],u_{\text{0-h}})\)
8. **C4** generates an estimate for the edge response time, \(\hat{\Delta}\) based on all packets exchanged so far.
9. _Offloading Decision:_ * _Proceed with offload, if_ \(\hat{\Delta}\leq\Delta_{\max}(\hat{x}[n_{0}],u_{\text{0-h}})\) _AND_ \(\Delta_{\max}(\hat{x}[n_{0}],u_{\text{0-h}})\geq 1\); i.e., proceed to transmit \(y[n_{0}]\) to the edge. Initialize offload duration counter: \(\Delta_{\text{cnt}}=1\)
1. _Otherwise, terminate offload period, and use local fail-safe._ Skip to _Unsuccessful Offload_ with \(\Delta_{\max}(\hat{x}[n_{0}],u_{\text{0-h}})\)=1.
1. \(\vdots\) \(\vdots\) \(\vdots\)

1. \([n_{0}+\Delta_{\text{cnt}}]\) _Offload in progress; no edge response and_ \(\Delta_{\text{cnt}}<\frac{\Delta_{\max}(\hat{x}[n_{0}])}{\Delta_{\max}(\hat{x} [n_{0}])}\)
2. Maintain zero-order hold of \(u[n_{0}+\Delta_{\text{cnt}}]=u_{\text{0-h}}\).
3. Increment \(\Delta_{\text{cnt}}\colon\Delta_{\text{cnt}}\leftarrow\Delta_{\text{cnt}}+1\).
4. \(\vdots\) \(\vdots\) \(\vdots\)

**Now, the current offload period ends in one of two ways:**

_I) Successful Offload: (resume timeline from_ \(n_{0}+\Delta_{\text{cnt}}\) _)_

1. \([n_{0}+\Delta\;]\) _Edge response received;_ \(\Delta=\Delta_{\text{cnt}}\leq\Delta_{\max}(\hat{x}[n_{0}],u_{\text{0-h}})\)
2. Apply received control action \(u[n_{0}+\Delta]=\mathcal{NN}_{c}(y[n_{0}])\).
3. Initiate local evaluation of \(\mathcal{NN}_{c}\) for next time interval.
4. Initiate local evaluation of \(\mathcal{NN}_{p}\) for next time interval.
5. \(n_{0}-\Delta\) becomes time \(n_{1}-1\) for the starting index of the next offload period. (See \(n_{0}-1\) time index above.)

_II) Unsuccessful Offload: (resume timeline from_ \(n_{0}+\Delta_{\text{cnt}}\))

1. \([n_{0}+\Delta_{\max}]\) _No edge response received, and safety expired;_ \(\frac{\Delta_{\text{cnt}}=\Delta_{\max}(\hat{x}[n_{0}],u_{\text{0-h}})}{\Delta_{ \text{cnt}}=\Delta_{\max}(\hat{x}[n_{0}],u_{\text{0-h}})}\)
2. Maintain original zero-order hold control \(u[n_{0}+\Delta_{\max}(\hat{x}[n_{0}],u_{\text{0-h}})]=u_{\text{0-h}}\) (there have been no updates.)
3. Initiate local evaluation of \(\mathcal{NN}_{c}\) for next time interval.
4. Initiate local evaluation of \(\mathcal{NN}_{p}\) for next time interval.
5. \(n_{0}-\Delta_{\max}(\hat{x}[n_{0}])\) becomes time \(n_{1}-1\) for the starting index of the next offload period. (See \(n_{0}-1\) time index above.)

In particular, note two crucial facts. First, if **C2** returns \(\Delta_{\max}(\hat{x},u)=0\), then it effectively forces pure on-vehicle evaluation of \(\mathcal{NN}_{c}\) and \(\mathcal{NN}_{p}\). Second, we ensured that an up-to-date estimate of the state is always available for both **C1** and **C2** before they have to act.

## 4. EnergyShield: Provably Safe Offloading

### Main Formal Result

#### 4.1.1. Formal Assumptions

We begin this section with a list of formal assumptions about the ADS. These are largely based around the structure of EnergyShield, as described in Section 3.

Assumption 1 (ADS Safety).: _Consider a fixed point in the plane as a stationary obstacle to be avoided by the ADS, and a disk or radius \(\bar{r}\) around the origin to be a set of unsafe states; see Figure 2._

Figure 3. EnergyShield Framework
**Assumption 2** (ADS Model).: _Let Assumption 1 hold. Thus, suppose that the ADS vehicle is modeled by the KBM dynamics in (1). Suppose further that interactions with this model happen in discrete time with zero-order hold. Let \(T\) be the sampling period._

**Assumption 3** (ADS Sensors).: _Let Assumptions 1 and 2 hold. Suppose the KBM-modeled ADS has access to samples of a sensor signal, \(s[n]\in\mathbb{R}^{N}\), at each discrete time step, and there is a perception NN, \(\mathcal{N}\nabla_{p}:s[n]\mapsto\chi[n]\), which maps the sensor signal at each discrete time to the (exact) KBM state at the same time instant, \(\chi[n]\)._

**Assumption 4** (ADS Control).: _Let Assumptions 1 - 3 hold. Suppose this KBM-modeled ADS vehicle has a NN controller, \(\mathcal{N}\nabla_{c}:s\mapsto\omega\), which at each sample has access to the sensor measurement \(s\)._

**Assumption 5** (ADS Local Computation).: _Let Assumptions 1 - 4 hold. Suppose that the output of \(\mathcal{N}\nabla_{p}\) and \(\mathcal{N}\nabla_{c}\) can be computed by ADS on-vehicle hardware in less than \(T\) seconds - i.e., not instantaneously. Thus, suppose that the control action is obtained with a one-sample computation delay when using on-vehicle hardware: i.e., the control action applied at sample \(n+1\) is \(\omega[n+1]=\mathcal{N}\nabla_{c}(s[n])\)._

#### 4.1.2. Component Design Problems

There are two central problems that need to be solved: i.e., corresponding to the design of the two main components of EnergyShield, **C1** and **C2** (see Section 3).

The solutions to these problems are deferred to Sections 4.2 and Section 4.3, respectively. We state them here in order to facilitate the statement of our main result in the next subsection.

**Problem 1** (Controller Shield Design (**C1**)).: _Let Assumptions 1 - 5 hold. Then the problem is to design: first, design functions \(h\) and \(\alpha\) such that they constitute a ZBF for the KBM (see); and then using this ZBF, design a controller shield, \(\mathfrak{S}\) for the KBM model. The resulting controller shield must have the following additional property for **a discrete-time version of the KBM** with zero-order-hold inputs:_

* _Let_ \(\chi[n_{0}-1]\) _and_ \(\chi[n_{0}]\) _be KBM states such that_ \(h(\chi[n_{0}-1]),h(\chi[n_{0}])>0\)_, and let_ \(\chi[n_{0}]\) _result from a feasible input_ \(\hat{\omega}[n_{0}-1]\) _applied in state_ \(\chi[n_{0}-1]\)_. Then the control action_ \[\hat{\omega}[n_{0}]=\mathfrak{S}(\chi[n_{0}-1],\omega[n_{0}])\] (9) _must yield a state_ \(\chi[n_{0}+1]\) _such that_ \(h(\chi[n_{0}+1])>0\)_; i.e., the controller shield preserves safety under discretization of the KBM and one-step estimation delay (associated with_ \(\mathcal{N}\nabla_{p}\)_), as in the case of no computations being offloaded._

**Problem 2** (Runtime Safety Monitor Design (**C2**)).: _Let Assumptions 1 - 5 hold, and assume that \(h\), \(\alpha\) and \(\mathfrak{S}\) solve Problem 1. Then the problem is to design a runtime safety monitor:_

\[\Delta_{max}:\mathbb{R}^{3}\times\Omega_{adm\text{irs}}\rightarrow\mathbb{N} \tag{10}\]

_with the following property:_

* _Let_ \(\chi[n_{0}-1]\) _be such that_ \(h(\chi[n_{0}-1])>0\)_. Then for constant control,_ \(\omega=\omega[n_{0}]\)_, applied to the discretized KBM starting from_ \(\chi[n_{0}-1]\) _the following is true:_ \[\forall n=0,\dots,\Delta_{max}(\chi[n_{0}-1],\omega[n_{0}])\cdot h(\chi[n_{0}- 1+n])>0\] (11) _i.e. the constant control_ \(\omega=\omega[n_{0}]\) _preserves safety for at least_ \(\Delta_{max}(\chi[n_{0}-1],\omega[n_{0}])\) _samples from state_ \(\chi[n_{0}-1]\)_._

_(The delay in \(\chi[n_{0}-1]\) accounts for the computation time of \(\mathcal{N}\nabla_{p}\).)_

#### 4.1.3. Main Result

Given solutions to these problems, it is straightforward to conclude our main formal result.

**Theorem 1**.: _Let Assumptions 1 - 5 hold, and assume a ZBF for the KBM dynamics, using which Problem 1 and Problem 2 can be solved._

_Then the offloading policy described in Section 3.3 preserves safety of the KBM-modeled ADS (Assumptions 1 and 2)._

The proof follows largely by construction. Each offload period is limited in duration by the runtime safety monitor; thus, a safety monitor that solves Problem 2 will ensure safety under the specified constant control action during the offload period. Then by the additional property of the controller shield in Problem 1, safety can be maintained after the offloading period ends: i.e., either by a deciding to perform a new offload if there remains significant safety margin, or by executing the shield in closed loop because there is no offload safety margin. 

**Corollary 1**.: _Let Assumptions 1 - 5 hold, and consider the ZBF for the KBM dynamics specified in Section 2.4. Then the controller shield in Section 4.2 uses this ZBF and solves Problem 1; likewise, the runtime monitor in Section 4.3 uses this ZBF and solves Problem 2. Hence, our implementation of EnergyShield is safe._

### KBM Controller Shield

Fortunately, we have access to a preexisting ZBF and controller shield designed for the KBM: see Section 2.4(C). That is, the ZBF is available after using the design methodology in (C) to choose the parameter \(\sigma\) (see Section 2.4); for simplicity, we will omit further discussion this design process. Thus for this section, we refer to a fully implemented controller shield as \(\mathfrak{S}_{\text{KBM}}\), with the understanding that it has been designed for the relevant KBM model and safety parameter \(\bar{r}\) (see Figure 2); viz. Assumptions 1 and 2.

Thus, the main requirement of this section is to alter \(\mathfrak{S}_{\text{KBM}}\) as necessary so that it satisfies the additional property required in Problem 1. This is the subject of the following Lemma, which also defines the alterations in question.

**Lemma 1**.: _Let Assumptions 1 - 5 hold as usual, and let \(\mathfrak{S}_{\text{KBM}}\) be a controller shield designed under these assumptions as per Section 2.4._

_Then there exists a \(\rho>0\) such that the following controller shield:_

\[\mathfrak{S}_{\text{KBM}}^{\rho}:((r,\xi,\upsilon),\omega)\mapsto\begin{cases} \mathfrak{S}_{\text{KBM}}((r-\rho,\xi,\upsilon),\omega)&r-\rho\geq r_{\min}(\xi) \\ \beta_{max}&r-\rho\geq r_{\min}(\xi)\wedge\xi\geq 0\\ -\beta_{max}&r-\rho\geq r_{\min}(\xi)\wedge\xi<0.\end{cases} \tag{12}\]

_solves Problem 1._

The proof of this Lemma is deferred to Appendix A.

A further remark is in order about Lemma 1. Note that the altered controller shield \(\mathfrak{S}_{\text{KBM}}^{\rho}\) maintains the energy efficient implementation of the controller shield \(\mathfrak{S}_{\text{KBM}}\) as designed in (C); indeed only two additional ReLU units are required, which amounts to a trivial per-evaluation increase in energy consumption.

### KBM Runtime Safety Monitor: Generating Safety Expiration Times

Recall that the runtime safety monitor of EnergyShield must provide an _expiration_ on the safety of the vehicle during an offload period,
throughout which only a single, fixed control input is applied. This expiration must come with a _provable guarantee_ that the vehicle safety is not compromised in the interim. In the formulation of EnergyShield and Problem 2, this means only that \(h_{\vec{r},\sigma}\) must remain non-negative until the expiration of the deadline provided by the runtime safety monitor: see the condition (11) of Problem 2.

This formulation is convenient because it means that the problem can again be analyzed in continuous time, unlike our consideration of Problem 1 above: the conversion back to discrete time involves a floor operation; and compensating for the one-sample state delay induced by computing \(\mathcal{NN}_{p}\) involves subtracting one sample from the result. That is, to solve Problem 2 and design an EnergyShield-safety monitor, it is sufficient provide a (real) time, \(v\), s.t.:

\[\forall t\in[0,v]\.\ h\big{(}\xi_{\alpha_{\alpha}[n_{0}]}^{\alpha,\text{dyn} \alpha_{\alpha}]}(t)\big{)}>0. \tag{13}\]

In other words, the flow of \(f_{\text{KBM}}\) started from \(\chi[n_{0}-1]\) and using constant control \(\omega[n_{0}]\) maintains \(h>0\) for the duration \([0,v]\). We emphasize again that such a \(v\) can be converted into the correct sample units expected for the output \(\Delta_{\max}(\chi[n_{0}-1],\omega[n_{0}])\) by using a floor operation and subtracting one. With this context, we have the following Lemma, which solves Problem 2.

Lemma 2 ().: _Let Assumptions 1 - 5 hold as usual. Let_

\[\Delta_{max}(\chi[n_{0}-1,\omega[n_{0}])\triangleq\max(\lfloor v(\chi[n_{0} -1],\omega[n_{0}])\rfloor-1,0) \tag{14}\]

_where \(v=v(\chi[n_{0}-1],\omega[n_{0}])\) solves the equation:_

\[\sqrt{2}\cdot L_{h_{\vec{r},\sigma}}\cdot\lVert f_{\text{KBM}}(\chi[n_{0}-1], \omega[n_{0}])\rVert_{2}\cdot v\cdot e^{L_{\text{KBM}}\cdot v}=\hbar(\chi[n_{ 0}-1]) \tag{15}\]

_for \(L_{h_{\vec{r},\sigma}}\) and \(L_{f_{\text{KBM}}}\) upper bounds on the Lipschitz constants of \(h_{\vec{r},\sigma}\) and \(f_{\text{KBM}}\), respectively._

_Then \(\Delta_{max}(\chi[n_{0}-1,\omega[n_{0}])\) so defined solves Problem 2._

The proof of Lemma 2 is deferred to Appendix B.

Lemma 2 specifies a complete solution to Problem 2, as claimed. However in its immediate form, it requires numerically solving (15) with each evaluation of \(\Delta_{\max}(\chi[n_{0}-1],\omega[n_{0}])\); i.e., each time a safety expiration time is requested from the runtime safety monitor (every sample in the case where the offloading period is terminated before offload). The nature of (15) is such that solving it numerically is not especially burdensome - especially compared to the NN evaluations it replaces; however, as a practical matter it is also possible to implement it as a LUT to achieve greater energy efficiency.

## 5. Experiments and findings

The purpose of this section is to assess the following key aspects of EnergyShield: (_i_) the extent of energy savings achievable compared to the conventional continuous local execution mode given a wide variety of network conditions and server delays, (_ii_) its ability to enforce the safety through obstacle collision avoidance, (_iii_) how representative the upper bounds of the edge response time (\(\Delta_{max}\)) are of the inherent risks existing in the corresponding driving context, and (_iv_) its generality when integrated with controllers of distinctive behavioral characteristics, in particular when it comes to different learnt driving policies.

### Experimental Setup

#### 5.1.1. Operational Policies

In addition to the baseline continuous local execution, we designate two EnergyShield offloading modes:

* _Eager:_ in which a new offloading interval is immediately started if either edge responses have been received at the ADS or \(\Delta_{max}\) expired.
* _Uniform:_ in which the start of a new offloading interval is always delayed until \(\Delta_{max}\) expires, regardless of whether edge responses have been received or not.

We define both these modes to reflect the attainable behavioral trade-offs of EnergyShield with regards to realizing an ideal control behavior or maximizing energy efficiency. This distinction is illustrated through the first offloading interval in Figure 4 in which the uniform EnergyShield tiles upon its retrieval of the edge responses until \(\Delta_{max}\) expires unlike the eager EnergyShield mode.

#### 5.1.2. Experimental Scenario

We perform our experiments using the CARLA open-source simulator for autonomous driving research (Garfani et al., 2018). We follow the setup proposed in (Krishna et al., 2018), and implement a similar experimental scenario. Basically, the scenario involves a four-wheel vehicle travelling from a starting position A to destination B along a 100m motorway track with 4 pedestrian obstacles in its path. The first obstacle spawns after 40m of the track, while the remaining spawning positions are uniformly spaced between the first obstacle's position and that of the final destination - with a potential \(\pm 10m\) variation along the longitudinal axis.

#### 5.1.3. Experimental Settings

Throughout this section, _all_ of our experiments are conducted under different combinations of the following two binary configuration parameters:

* **S**: this binary variable indicates whether the Controller Shield component is _active_ (see Section 3.2).
* **N**: this binary variable indicates whether this is a more challenging, "noisy" version of the experimental test case.

In particular, the noisy version entails perturbing the obstacles' spawning positions by additional values sampled from a normal distribution \(\mathcal{N}(0,1.5m)\) along both the longitudinal and latitudinal axis. For example, the configuration settings (S = 1, N = 0) indicate that the experiment was performed with Controller Shield active and with no perturbations in the obstacles' spawning positions.

#### 5.1.4. Simulation Setup

For the controller model, its first stage entails two concurrent modules: an object detector as the large NN model of the ADS and a \(\beta\) Variational Autoencoder (\(\beta\)-VAE) providing additional latent feature representations of the driving scene. Both components operate on 160\(\times\)80 RGB images from the vehicle's attached front-facing camera. In the subsequent stage, a Reinforcement Learning (RL) agent aggregates the detector's bounding box predictions, latent features, and the inertial measurements (\(\delta_{f}^{c}\), \(v\), and \(a\)) to predict vehicle control actions (steering angle and throttle).

Figure 4. The operational policies in our experiments given base time window \(\tau\). Darker instances imply local execution.
The inertial measurements can be fetched directly from CARLA, whose positional and orientation measurements are also used directly to calculate \(r\) and \(\xi\) relative the vehicle's current nearest obstacle for obstacle state estimation. We trained the RL controller agents using a reward function, \(\mathcal{R}\), that aims to maximize track completion rates through collision avoidance while minimizing the vehicle's center deviance from the primary track. For the definition of \(\mathcal{R}\) as well as details of the RL agents see Appendix C.

#### 5.1.5. Performance Evaluations

We use a pretrained ResNet-152 for our object detector and benchmark its performance in terms of latency and energy consumption when deployed on the industry-grade Nvidia Drive PX2 Autochaurfer ADS. We found that a single inference pass on the ResNet-152 took \(\approx\) 16 ms, and accordingly, we fixed the time-step in CARLA at 20 ms since the detector-in-the-loop was the simulation's computational bottleneck. To evaluate the wireless transmission power, we use the data transfer power models in (Kang et al., 2018) and assume a Wi-Fi communication link.

#### 5.1.6. Wireless Channel Model

We model the communication overheads between the ego vehicle and edge server as:

\[L_{comm}=L_{Tx}+L_{que}\ \ s.t.,\ L_{Tx}=\frac{data\ size}{\phi}, \tag{16}\]

where \(L_{que}\) represents potential queuing delays at the server whereas \(L_{Tx}\) is the transmission latency defined by the size of the transmission data, \(data\_size\), over the experienced channel throughput, \(\phi\). Here, we assume \(\phi\) as the "effective" channel throughput experienced at the ego vehicle, which takes into consideration potential packet drops, retransmissions, etc. We leverage a Rayleigh distribution model as in (Kang et al., 2018) to sample throughput values \(\phi\) - \(Rayleigh(0,\sigma_{\phi})\) with zero mean and \(\sigma_{\phi}\) scale (default \(\sigma_{\phi}\)=20 Mbps). Details on the modelling of queuing delays, \(q\), and the server response time estimation (i.e., \(\hat{\Delta}\)) are provided in Appendix C.

### EnergyShield Evaluations

The purpose of this experiment is to assess the controller's performance when supplemented with EnergyShield in terms of energy efficiency and safety. For every configuration of S and N, we run the test scenario for 35 episodes and aggregate their combined results.

**Energy Efficiency:** We first assess the energy efficiency gains offered by EnergyShield compared to the baseline continuous local execution. As illustrated Figure 5, the left barplot demonstrates that both modes of EnergyShield substantially reduce the energy consumption footprint of the NN compared to local execution across all S and N configurations. For instance, under the default configuration (S = 0, N = 0), EnergyShield energy reductions reach 20% and 40.4% for the eager and uniform modes, respectively. These numbers further improve for the subsequent configurations in which N = 1 or S = 1. Upon inspection, we find that this is the result of the ego vehicle encountering more instances in which obstacles are not in the direct line-of-sight of its heading. The reasons being that at N = 1, some obstacles can be displaced out of the primary lane that the ego vehicle follows to complete the track, whereas at S = 1, such instances result from the Controller Shield applying corrective behaviors on the NN's predicted steering outputs, resulting in more tangential orientations of the vehicle with respect to the obstacles (i.e., \(\xi\rightarrow\pm\pi/2\)). Accordingly, large values of \(\Delta_{max}\) - about 4-5 time samples (equivalent to 80-100 ms) - are increasingly sampled, and that automatically translates into more offloading decisions. For instance at (S = 1, N = 0), the energy efficiency gains reach 24.3% and 54.6% for the respective eager and uniform modes.

**Safety Evaluation:** To assess the EnergyShield's ability to enforce safety, we designate track completion rates (TCR %) as a comparison metric to signify the proportion of times the vehicle was able to complete the track without collisions. Taking the local execution mode as the test scenario, the right barplot of Figure 5 shows that without an active Controller Shield (S = 0), collisions with the pedestrian obstacles cause the TCR% to be 65.7% at N = 0, and even less at 22.9% for the noisy test case (N = 1). However, when the Controller Shield is active (S = 1), collisions are completely avoided and the TCR (%) values jump to 100% for both cases. This is also visible through the respective improvements in \(\mathcal{R}\) which reached 13.3% and 61.1%. To further demonstrate such occurrences, we analyze in Figure 6 the ego vehicle's chosen trajectories across 3 episodes of dissimilar (S, N) configurations. As shown, the (S = 0, N = 0) instance incurs a collision with the pedestrian object and does not complete the track. An active Controller Shield (S = 1), however, enforces a left or right corrective maneuvering action for obstacle avoidance and maintaining safety. Pictorial illustrations of these actions are also provided in the Figure.

**Energy vs. Distance:** To assess how representative the \(\Delta_{max}\) upper bounds provided by the Runtime Safety Monitor are of the corresponding driving scene context, we examine EnergyShield's energy consumption at different distances from the nearest obstacle (\(r\)). The hypothesis is that larger \(r\) values imply relatively "safer" driving situations, which would result in larger values of \(\Delta_{max}\) to be sampled, and accordingly more offloading instances enhancing the NN's energy efficiency. As shown in Figure 7, we plot the average experienced normalized energy ratings of the two modes of EnergyShield with respect to local execution against \(r\) across every configuration's set of 35 episodes. Each tick on the horizontal axis accounts for an entire range of 1m distances rather than a single value - e.g., a value of 2 on the horizontal axis encompasses all distances in the range [2 - 3). At close distances (\(r\) < 4m), we find that EnergyShield modes incur almost the same energy consumption overhead as that from the default local execution. This is mainly accredited to the Runtime Safety Monitor recognizing the higher risks associated with the close proximity from the objects, and accordingly outputting smaller values of \(\Delta_{max}\) that can only be satisfied by local execution. As the distance from obstacles increases, so do the values of \(\Delta_{max}\), causing a gradual increase in the number of offloading instances, followed by a progressive reduction in energy consumption. For instance, the eager and uniform modes

Figure 5. EnergyShield’s energy efficiency gains with respect to continuous local execution (left) and safety analysis in terms of the \(\mathcal{R}\) evaluation and % TCR (right).
achieve 32% and 66% respective reductions in energy consumption at \(r=13\) m for the (S = 1, N = 1) configuration. Even more so, all configurations of the respective eager and uniform modes at the (\(r\) > 20m) bracket realize 33% and 67% respective energy gains.

### Wireless Channel Variations

In this experiment, we assess how the performance gains of EnergyShield are affected given variations of the wireless channel conditions. Specifically, given potential changes in the channel throughput, \(\phi\), or the queuing delays, \(q\), we investigate to what extent do the energy savings offered by EnergyShield vary. Additionally, we examine for every set of experimental runs what percentage of their total elapsed time windows were extra transition windows needed to complete a single offloading instance, which we denote by the % _Extra Transit Windows_ metric. From here, we first analyze such effects when varying \(\sigma_{\phi}\in\{20,10,5\}\) Mbps given a fixed \(q=1\) ms, and then when varying \(q\in\{10,20,50\}\) ms given a fixed \(\sigma_{\phi}=10\) Mbps. For the uniform EnergyShield, we notice in Figure 8 that the % _Extra Transit Windows_ drops for the contrasting conditions of high throughput (\(\sigma_{\phi}=20\) Mbps) and high queuing delays (\(q=50\) ms), reaching medians of 7% and 8%, respectively. This can be justified in light of how the benign channel conditions (\(\sigma_{\phi}=20\) Mbps) indicate that the majority of offloading instances are concluded in a single time window with no considerable need for extra transmission windows. Whereas at unfavorable wireless conditions (\(q=50\) ms), \(\hat{\Delta}\) values often exceed \(\Delta_{max}\), leading EnergyShield to opt for local execution more often so as to avoid wireless uncertainty, lowering the total number of transmission windows alltogether. Such effects are also visible in the twin Figure 9 as EnergyShield's energy consumption varies across these contrasting conditions, reaching respective medians of 45% and 93% of the local execution energy at \(\sigma_{\phi}\)=20 and \(q\)=50.

### Generality

To assess the generality of EnergyShield, we train 3 additional RL controllers to evaluate how consistent EnergyShield is with regards to maintaining safety guarantees, and how the energy efficiency gains would vary given a distinctive driving behavior for each agent. Hence, we repeat the primary test runs for the additional controllers in which we average the energy consumption and TCR across 35 episodes of each viable (S, N) configuration. We also report the average center deviance (CD) experienced by the ego vehicle from the primary track lane as a metric to characterize the different driving behaviors of each controller. In our experimental test case, larger CD imply larger \(r\) values, that is, controllers with low values of CD tend to drive closer to the obstacles at higher risks of collisions (maximizing \(\mathcal{R}\) through minimizing CD), whereas larger values of CD indicate the agents have learnt to take the farther lanes of the track in order to maximize track completions through prioritizing collision avoidance (maximizing \(\mathcal{R}\) through maximizing TCR). In the following, we highlight the key findings and refer the reader to Table 1 in Appendix C for the detailed results.

Figure 8. Analyzing the % extra transit windows over 35 episodes of uniform EnergyShield given various \(\sigma_{\phi}\) and \(q\).

Figure 6. Top: Example trajectories followed by the ego vehicle with the start point at the top. Bottom: illustration of how the ego vehicle under the aforementioned operational modes behaved in reaction to the first encountered obstacle.

Figure 7. Normalized Energy Gains for the eager (_solid_) and uniform (_dashed_) EnergyShield modes with respect to the distance from obstacle (\(r\)) in m.

Figure 9. Analyzing the Normalized Energy cons. over 35 episodes of uniform EnergyShield given various \(\sigma_{\phi}\) and \(q\).
Our first key finding is that given S = 0, TCR (%) is dependent on CD ratings as only the controllers with CD \(>\) 5m consistently achieve the 100% TCR. At S = 1, however, this dependency no longer holds at S = 1 when the Controller Shield enforces the obstacle avoidance safety guarantees, pushing all controllers to achieve 100% TCR irrespective of CD values. The other interesting finding here is that across both modes of EnergyShield, the average energy consumption is less for controllers with larger CD ratings. For instance at (S = 1, N = 1), when the RL controllers are arranged in an increasing order of their CD values 2.8\(\rightarrow\)3.6\(\rightarrow\)5.4\(\rightarrow\)5.7 m, the average energy consumption per inference decreases in the respective order 53.1\(\rightarrow\)45.7\(\rightarrow\)42.1\(\rightarrow\)39.8 mJ. Indeed, this highlights EnergyShield's capability of conducting _safe_ and _effective_ context-aware offloading, especially given how the Runtime Safety Monitor provides large \(\Delta_{max}\) to realize more energy gains in the safer situations (e.g., larger distances from obstacles), and how the Controller Shield always maintains safety guarantees independent of offloading decisions.
