ma: add diagrams
This commit is contained in:
parent
64eac66a8f
commit
c9f9d26dff
4 changed files with 56 additions and 40 deletions
1
ma/resources/prototype_schema.drawio
Executable file
1
ma/resources/prototype_schema.drawio
Executable file
File diff suppressed because one or more lines are too long
BIN
ma/resources/prototype_schema.pdf
Executable file
BIN
ma/resources/prototype_schema.pdf
Executable file
Binary file not shown.
Binary file not shown.
1
ma/safety_reset.pdf
Symbolic link
1
ma/safety_reset.pdf
Symbolic link
|
|
@ -0,0 +1 @@
|
|||
/mnt/c/Users/jaseg/shared/safety_reset.pdf
|
||||
|
|
@ -352,7 +352,14 @@ situations where that was not previously economically possible\footnote{
|
|||
introduction of smart metering\cite{vseaes01} cynically writes that remotely controllable load switches ``lead a new
|
||||
tenant to swiftly register'' with the utility company. This whitepaper completely vanished from their website some
|
||||
time after publication, but the internet archive has a copy.
|
||||
}.
|
||||
}. Figure \ref{fig_smgw_schema} shows a schema of the smart metering installation in a typical household.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics{resources/smgw_usage_scenario}
|
||||
\caption{A typical usage scenario of a smart metering system in a typical home.}
|
||||
\label{fig_smgw_schema}
|
||||
\end{figure}
|
||||
|
||||
To the customer the utility of a smart meter is largely limited to the convenience of being able to read it without
|
||||
going to the basement. In the long term it is said that there will be second-order savings to the customer since
|
||||
|
|
@ -1619,6 +1626,13 @@ realistically be up to $\mathcal O\left(10^3\right)$, which is easily enough for
|
|||
|
||||
\chapter{Practical implementation}
|
||||
|
||||
To validate the practical feasibility of the theoretical concepts we laid out in the previous chapter we decided to
|
||||
build a prototype of a safety reset controller. In this section we describe the reasoning behind the components of this
|
||||
prototype and the engineering that went into its firmware. The prototype consists of a smart meter whose application
|
||||
microcontroller is reset by a prototype reset controller on an external circuit board. We lay out how we extensively
|
||||
tested all parts of our firmware implementation. We conclude with results of a practical end-to-end experiment
|
||||
exercising every part of our prototype.
|
||||
|
||||
\section{Data collection for channel validation}
|
||||
|
||||
To design a solid system we needed to parametrize mains frequency variations under normal conditions. To set modulation
|
||||
|
|
@ -2083,8 +2097,6 @@ our MLE's symbol chain detection. High threshold factors lead the algorithm to
|
|||
some degree this can be compensated by our later interpolation step for missing peaks but in the extreme will also break
|
||||
demodulation. In our simulations good values lie in the range from $4.0$ to $5.5$.
|
||||
|
||||
% FIXME algo flow chart
|
||||
|
||||
Figure \ref{dsss_thf_amplitude_5678} contains plots of demodulator sensitivity like the one in Figure
|
||||
\ref{dsss_gold_nbits_overview}. This time there is one color-coded trace for each threshold factor between $1.5$ and
|
||||
$10.0$ in steps of $0.5$. We can see a clear dependency of demodulation performance from trheshold factor with both very
|
||||
|
|
@ -2159,10 +2171,8 @@ moving the signal band into noisier spectral regions (cf.\ Figure \ref{freq_meas
|
|||
Figure \ref{freq_meas_spectrum} we can see that noise energy is mostly concentrated at lower frequencies, so
|
||||
shifting our signal up in frequency will reduce the amount of noise the decoder sees behind the correlator by
|
||||
shifting the band of interest into a lower-noise spectral region. For a practical implementation chip duration
|
||||
is limited by physical factors such as the maximum modulation slew rate ($\frac{\text{d}P}{\text{d}t}$), the
|
||||
maximum Rate-Of-Change-Of-Frequency (ROCOF, $\frac{\text{d}f}{\text{d}t}$) the grid can tolerate and possible
|
||||
inertial effects limiting response of frequency to load changes at certain load levels.
|
||||
% FIXME are these inertial effects likely? Ask an expert.
|
||||
is limited by physical factors such as the maximum modulation slew rate ($\frac{\text{d}P}{\text{d}t}$) and the
|
||||
maximum Rate-Of-Change-Of-Frequency (ROCOF, $\frac{\text{d}f}{\text{d}t}$) the grid can tolerate.
|
||||
}
|
||||
\label{chip_duration_sensitivity}
|
||||
\end{figure}
|
||||
|
|
@ -2334,13 +2344,21 @@ We based our safety reset demonstrator firmware on the grid frequency sensor fir
|
|||
\ref{sec-ch-sim} to embedded C code. After validating the C translation in extensive simulations we integrated our code
|
||||
with a reed-solomon implementation and a libsodium-based implementation of the cryptographic protocol we designed in
|
||||
sec.\ \ref{sec-crypto}. To reprogram the target MSP430 microcontroller we ported over the low-level bitbang JTAG driver
|
||||
of mspdebug\footnote{\url{https://github.com/dlbeer/mspdebug}}.
|
||||
of mspdebug\footnote{\url{https://github.com/dlbeer/mspdebug}}. See Figure \ref{fig_demo_sig_schema} for a schematic
|
||||
overview of signal processing in our demonstrator.
|
||||
|
||||
For all computation-heavy high-level modules of our firmware such as the DSSS demodulator or the grid frequency
|
||||
estimator we wrote test fixtures that allow the same code that runs on the microcontroller to be executed on the host
|
||||
for testing. These test fixtures are very simple C programs that load input data from a file or the command line, run
|
||||
the algorithm and print results on standard output.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{resources/prototype_schema}
|
||||
\caption{The signal processing chain of our demonstrator.}
|
||||
\label{fig_demo_sig_schema}
|
||||
\end{figure}
|
||||
|
||||
\section{Grid frequency modulation emulation}
|
||||
|
||||
To emulate a modulated grid frequency signal we superimposed a DSSS-modulated signal at the proper amplitude with
|
||||
|
|
@ -2351,8 +2369,13 @@ compensated for at the transmitter by selecting appropriate modulation parameter
|
|||
the receiver by equalization with a matched filter.
|
||||
|
||||
\section{Experimental results}
|
||||
|
||||
After extensive simulations and testing of the individual modules of our solution we proceeded to conduct a real-world
|
||||
experiment. We tried the demonstrator setup with an emulated noisy DSSS signal in real-time. Our experiment went without
|
||||
any issues and the firmware implementation correctly reset the demonstrator's meter. We were happy to see that our
|
||||
extensive testing paid off: The demonstrator setup worked on its first try.
|
||||
% TODO add some pictures of the finished demo setup in action
|
||||
% FIXME
|
||||
% FIXME maybe add an SER curve here?
|
||||
|
||||
\section{Lessons learned}
|
||||
|
||||
|
|
@ -2420,21 +2443,19 @@ from ARM's CMSIS signal processing library.
|
|||
\section{Precise grid characterization}
|
||||
|
||||
We based our simulations on a linear relationship between generation/consumption power imbalance and grid frequency.
|
||||
Our literature study suggests that this is an appropriate first-order approximation. %FIXME citation
|
||||
We kept modulation bandwidth in our simulations inside a \SIrange{1000}{100}{\milli\hertz} frequency band that we reason
|
||||
is most likely to exibit this linear behavior in practice. At lower frequencies primary control kicks in. With the
|
||||
frequency delta thresholds specified for primary control systems\cite{entsoe04} this will likely lead to significant
|
||||
non-linear effects. At higher frequencies grid frequency estimation at the receiver becomes more complex. Higher
|
||||
frequencies also come close to modes of mechanical oscillation in generators (usually at \SI{5}{\hertz} and
|
||||
above\cite{crastan03}).
|
||||
Our literature study suggests that this is an appropriate first-order approximation\cite{crastan03}. We kept modulation
|
||||
bandwidth in our simulations inside a \SIrange{1000}{100}{\milli\hertz} frequency band that we reason is most likely to
|
||||
exibit this linear behavior in practice. At lower frequencies primary control kicks in. With the frequency delta
|
||||
thresholds specified for primary control systems\cite{entsoe04} this will likely lead to significant non-linear effects.
|
||||
At higher frequencies grid frequency estimation at the receiver becomes more complex. Higher frequencies also come
|
||||
close to modes of mechanical oscillation in generators (usually at \SI{5}{\hertz} and above\cite{crastan03}).
|
||||
|
||||
Some limited analysis of the above concerns can be done through established dynamic grid simulation
|
||||
models\cite{semerow01,entsoe05}. Presumably out of safety concerns these models are only available under non-disclosure
|
||||
agreements. Integrating even just NDA-encumbered results stemming from such a model in an open-source publication such as
|
||||
this one poses a logistical challenge which is why we decided to leave this topic for a separate future work.
|
||||
After detailed model simulation we ultimately aim to validate our results experimentally. Assuming linear grid behavior
|
||||
even under very small disturbances a small-scale experiment is an option. Such a small-scale experiment would require
|
||||
very long integration times.
|
||||
An analysis of the above concerns can be performed using dynamic grid simulation models\cite{semerow01,entsoe05}.
|
||||
Presumably out of safety concerns these models are only available under non-disclosure agreements. Integrating
|
||||
NDA-encumbered results stemming from such a model in an open-source publication such as this one poses a logistical
|
||||
challenge which is why we decided to leave this topic for a separate future work. After detailed model simulation we
|
||||
ultimately aim to validate our results experimentally. Assuming linear grid behavior even under very small disturbances
|
||||
a small-scale experiment is an option. Such a small-scale experiment would require very long integration times.
|
||||
|
||||
Given a frequency characteristic of \SI{30}{\giga\watt\per\hertz} a stimulus of \SI{10}{\kilo\watt} yields $\Delta f =
|
||||
\SI{0.33}{\micro\hertz}$. At an estimated \SI{20}{\milli\hertz} of RMS noise over a bandwidth of interest this results
|
||||
|
|
@ -2462,10 +2483,9 @@ be the standardization of the backend operation including key management, coörd
|
|||
Since the proposed system adds significant cost and development overhead at no immediate benefit to either consumer or
|
||||
utility company it is unlikely that it would be adopted voluntarily. Market forces limit what long-term planning utility
|
||||
companies can do. An advanced mitigation such as this one might be out of their reach on their own and might require
|
||||
regulatory intervention to be implemented. To regulatory authorities a system such as this one provides a powerful
|
||||
primitive to guard against attacks. Due to the low-level approach our system might allow a regulatory authority to
|
||||
restore meters to a safe state without the need of fine-grained control of implementation details such as application
|
||||
network protocols.
|
||||
regulatory intervention to be implemented. To regulatory authorities a system such as this one provides a primitive to
|
||||
guard against attacks. Due to the low-level approach our system might allow a regulatory authority to restore meters to
|
||||
a safe state without the need of fine-grained control of implementation details such as application network protocols.
|
||||
|
||||
A regulatory authority might specify that all smart meters must use a standardized reset controller that on command
|
||||
resets to a minimal firmware image that disables external communication, continues basic billing functions and enables
|
||||
|
|
@ -2478,17 +2498,12 @@ regulatory authority as the \emph{reset authority} they would likely be able to
|
|||
managing root keys for other government systems to also manage safety reset keys. Availability and security requirements
|
||||
of safety reset keys do not differ significantly from those for other types of root keys.
|
||||
|
||||
\section{Practical implementation}
|
||||
%FIXME
|
||||
|
||||
|
||||
\section{Zones of trust}
|
||||
In our design, we opted for a safety reset controller
|
||||
% FIXME is "safety reset" the proper name here? We need some sort of branding, but is this here really about "safety"?
|
||||
in form of a separate micocontroller entirely separate from whatever application microcontroller the smart meter design
|
||||
is already using. This design nicely separates the meter into an untrusted application (the core microcontroller) and
|
||||
the trusted reset controller. Since the interface between the two is simple and logically one-way, it can be validated
|
||||
to a high standard of security.
|
||||
|
||||
In our design, we opted for a safety reset controller in form of a separate micocontroller entirely separate from
|
||||
whatever application microcontroller the smart meter design is already using. This design nicely separates the meter
|
||||
into an untrusted application (the core microcontroller) and the trusted reset controller. Since the interface between
|
||||
the two is simple and logically one-way, it can be validated to a high standard of security.
|
||||
|
||||
Despite these security benefits, the cost of such a separate hardware device might prove high in a mass-market rollout.
|
||||
In this case, one might attempt to integrate the reset controller into the core microcontroller in some way. Primarily,
|
||||
|
|
@ -2503,11 +2518,11 @@ discrete microcontroller for the reset controller.
|
|||
|
||||
The more likely approach to reducing cost overhead of the reset controller would be to employ virtualization
|
||||
technologies such as ARM's TrustZone in order to incorporate the reset controller firmware into the application firmware
|
||||
on the same chip without compromising the reset controller's security or disturbing the application firmware's
|
||||
on the same processor core without compromising the reset controller's security or disturbing the application firmware's
|
||||
operation.
|
||||
|
||||
TrustZone is a virtualization technology that provides a hardware-assisted privileged execution domain on at least one
|
||||
of the microcontrollers cores. In traditional virtualization setups a privileged hypervisor is managing several
|
||||
of the microcontroller's cores. In traditional virtualization setups a privileged hypervisor is managing several
|
||||
unprivileged applications sharing resources between them. Separation between applications in this setup is longitudinal
|
||||
between adjacent virtual machines. Two applications would both be running in unprivileged mode sharing the same cpu and
|
||||
the hypervisor would merely schedule them, configure hardware resource access and coördinate communication. This
|
||||
|
|
@ -2526,7 +2541,7 @@ microcontroller providing this type of virtualization on the one hand and the co
|
|||
virtualization on the other hand. Virtualization systems such as TrustZone are still orders of magnitude more complex to
|
||||
correctly configure than it is to simply use separate hardware and secure the interfaces in between.
|
||||
|
||||
\chapter{Alternative use of grid frequency modulation}
|
||||
\chapter{Alternative uses of grid frequency modulation}
|
||||
% FIXME random beacons? funky consensus protocols? proof of knowledge/cryptographic notary service?
|
||||
|
||||
\chapter{Conclusion}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue