text:
\section{How to Use this Template}

\input{tex/intro_section_v02}
\input{tex/relwork_v02}
\input{tex/arch_v02}
\input{tex/discussion_v02}
\input{tex/use_v02}
\input{tex/concl_v02}

\input{tex/appendixA_v02}

\authorcontributions{Conceptualization, Sorin~Grigorescu, Bogdan~Trasnea and Federico~Lombardi; methodology, Sorin~Grigorescu, Tiberiu~Cocias, Bogdan~Trasnea, Andrea~Margheri, Federico~Lombardi and Leonardo~Aniello; software, Sorin~Grigorescu, Tiberiu~Cocias and Bogdan~Trasnea; validation, Sorin~Grigorescu, Tiberiu~Cocias, Bogdan~Trasnea and Federico~Lombardi; formal analysis, Andrea~Margheri, Federico~Lombardi and Leonardo~Aniello; investigation, Sorin~Grigorescu and Federico~Lombardi; resources, Sorin~Grigorescu, Tiberiu~Cocias, Bogdan~Trasnea and Federico~Lombardi; data curation, Sorin~Grigorescu, Tiberiu~Cocias, Bogdan~Trasnea; writing--original draft preparation, Federico~Lombardi Andrea~Margheri, Leonardo~Aniello and Bogdan~Trasnea; writing--review and editing, Federico~Lombardi; visualization, Federico~Lombardi; supervision, Leonardo~Aniello; project administration, Sorin~Grigorescu; funding acquisition, Sorin~Grigorescu. All authors have read and agreed to the published version of the manuscript.

}

\funding{This research was funded by the European Commission under the CyberKit4SMEs project, grant number 883188.

}

\conflictsofinterest{The authors declare no conflict of interest.

}

\vspace{2cm}
\abbreviations{The following abbreviations are used in this manuscript:\\

\noindent
\begin{tabular}{@{}ll}
ADAS & Advanced Driver Assistant Systems\\
ADTF & Automotive Data and Time-Triggered Framework\\
AI & Artificial Intelligence\\
AV & Autonomous Vehicle\\
CNN & Convolutional Neural Network\\
DL & Deep Learning\\
dSPS & distributed Stream Processing Systems\\
DNN & Deep Neural Network\\
DP & Differential Privacy\\
EB & EletktroBit\\
GOL & Generative One-shot Learning\\
GPU & Graphic Processing Unit\\
HiL & Hardware-in-the-Loop\\
IoT & Internet-of-Things\\
IoU & Intersection over Union\\
ML & Machine Learning\\
MLP & Multi-Layer Perceptron\\
MPC & Multi-Party Computation\\
OTA & Over-the-Air\\
ReLu & Rectified Linear Unit\\
RM & Resource Manager\\
RNN & Recurrent Neural Network\\
ROS & Robotic Operative System\\
SiL & Software-in-the-Loop\\
TC & Training Coordinator\\
\end{tabular}}

\reftitle{References}

\externalbibliography{yes}

\section{}\label{appendixA}
\unskip

A hybrid deployment over cloud and edge resources allows to significantly increase the level of parallelism in AI Inference Engine development.
To give an idea about the scale of improvement that parallelisation can bring to DNN training, we present a toy example with
an experimental evaluation where two DNNs, i.e., a Multi-Layer Perceptron (MLP) and a CNN, are trained. The MLP has 2 hidden layers of 800 units each, followed by a softmax output layer of 10 units with 20\% dropout to input data and 50\% dropout to both hidden layers. The CNN has 2 convolutional layers with 32 kernels of size 5x5 strided and padded, a fully-connected layer of 256 units with 50\% dropout on its inputs and a 10-unit output layer with 50\% dropout on its inputs.
We compare the time required to train them by using a CPU, i.e. low level of parallelism, and a GPU, higher parallelism.

The experimental evaluation was carried out on a Dell Precision T7610 server, equipped with a Intel Xeon E5-2660 v2 CPU, 8GB of RAM, and with two GPUs, namely Tesla K20c and Nvidia Quadro K4000. The DNNs were developed in Python with Lasagne, by relying on Theano to exploit the CUDA GPU libraries.
The used dataset is based on MNIST, with a training set of 60k samples and a test set of 10k samples.
The tests aim at comparing: i) the training accuracy of the MLP and the CNN, after the same number of training iterations and ii) the training time on the available CPU and GPUs. Optimal settings for each network were computed based on a Q-Learning approach~\cite{lombardi2017elastic} that can automatically apply the dropout to minimize overfitting.

Fig.~\ref{fig:accuracy} reports the accuracy results for the two networks during training. The CNN achieves better accuracy than the MLP, being over 98\% in 5 epochs, while the MLP requires about 50 epochs. The maximum accuracy of the CNN is 99.21\% versus 98.56\% of the MLP.
Fig.~\ref{fig:time-mlp} and \ref{fig:time-cnn} report, respectively for MLP and CNN, the performance of training an epoch on the different hardware devices. As expected, training with both the GPUs is much faster than with the CPU. The epoch training time for MLP (resp., CNN) on the GPU Tesla and Quadro are $\approx 14$ and $\approx 6$  (resp., $\approx 73$ and $\approx 38$) times faster than on the CPU.
Notice how the Tesla is about 2 times faster than the Quadro.

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale=0.60]{figs/use_case_env_per_plot_acc.png}
		\caption{\textbf{Accuracy comparison between MLP and CNN.}}
		\label{fig:accuracy}
	\end{center}
	\vspace{-1em}
\end{figure}

\begin{figure}[t]
	\centering
	\subfloat[Comparison for training an epoch of MLP.]{\label{fig:time-mlp}\includegraphics[scale=0.65]{figs/time-mlp.png}}
	\subfloat[Comparison for training an epoch of CNN.]{\label{fig:time-cnn}\includegraphics[scale=0.65]{figs/time-cnn.png}}
	\caption{\textbf{Performance evaluation of the two types of DNNs}}

	\label{fig:reg_GFS_GFPNet}
\end{figure}
\section{EB-AI Toolchain}
\label{sec:architecture}

In the following, we describe the proposed EB-AI toolchain used to design, train and evaluate the AI Inference Engines. The engines represent application deployment wrappers for trained DNN models, which are used to build driving functions inside EB Robinos$^{\circledR}$, which is Elektrobit's autonomous driving system~\footnote{EB Robinos --- \url{https://www.elektrobit.com/products/automated-driving/eb-robinos/}}.

\subsection{V-Model and Workflow}
\label{sec:v-model}

Automotive software engineering still demands a robust and predictable development cycle. The software development process for the automotive sector is subject to several international standards, namely Automotive SPICE and ISO 26262~\cite{Salay2017}. Accepted standards, as far as the software is concerned, rely conceptually on the traditional V-Model development lifecycle. It is important to approach deep learning from a more controlled V-model perspective in order to address a lengthy list of challenges, such as the requirements for the training, validation and test datasets, the criteria for the data definition and preprocessing, as well as the impact of hyperparameters tuning.

In Fig.~\ref{fig:NN-V-Model-Approach} we propose a data driven V-Model for prototyping and development within EB-AI. The first two steps regard \textit{data definition} and \textit{data normalization and cleaning}. These are used to define the \textit{AI inference engine architecture}, where we properly configure the layers of the DNN and select the input training data according to the pre-processed datastreams. We then have the \textit{AI training \& implementation} step, where we train the DNN model to the requirements of the application. The trained model is converted automatically to a format that can be deployed within the autonomous vehicle. The converted model represents the \textit{AI Inference Engine} which is integrated and tested in different driving scenarios. According to the results obtained at different levels within the data driven V-Model, we can start the \textit{Verification and Validation} process, where we refine the inference engine.

This circular approach allows the EB-AI architecture to employ continuous learning, where DNNs can improve their accuracy overtime. To perform this task, we proposed a generative technique to compute synthetic data that can be used in the training process based on the GOL algorithm~\cite{grigorescu2018generative}.

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale=0.63]{NN-V-Model-Approach.png}
		\caption{\textbf{Data driven V-Model development of AI Inference Engines}. The proposed V-model encompasses a synergy of data driven SiL and HiL design, training and evaluation of AI components.}
		\label{fig:NN-V-Model-Approach}
	\end{center}

\end{figure}

\begin{figure*}
	\centering
	\begin{center}
		\includegraphics[scale=0.27]{workflow.pdf}
		\caption{\textbf{AI Inference Engines design, training and evaluation workflow within EB-AI}. The workflow builds on top of the proposed data driven V-model from Fig.~\ref{fig:NN-V-Model-Approach}.}
		\label{fig:eb_ai_flow}
	\end{center}

\end{figure*}

Fig.~\ref{fig:eb_ai_flow} details the workflow for AI Inference Engines design, deployment and testing based on the data driven V-Model. Phase 1 consists in defining the problem space and collecting the necessary data for the training process. In this phase, the data is pre-processed, annotated, normalized and filtered. In phase 2 we design the DNN architecture, activation functions, structure of the hidden layers and output nodes. Phase 3 deals with the tuning of the DNN, that is, all hyperparameters necessary for the training phase, such as the learning rate, loss function, regularization strategy and accuracy metrics.

Once the DNN setting has been completed, we deploy the DNNs among the cloud nodes in phase 4 and start the training in phase 5. In this phase we feed the DNN both with real sensory data, as well as with synthetic data, generated in a parallel workflow branch (phases 2.1-2.3). After training, the DNN is evaluated and redesigned if necessary (phase 6). The output of the training and evaluation phases is the \textit{AI Inference Engine} (phase 7). This is then deployed among the edge device in the car (phase 8) and evaluated again with respect to in-car performance measures.

\subsection{EB-AI Architecture}
\label{sec:detailed_architecture}

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale=0.3]{architecture}
		\caption{\textbf{EB-AI cloud architecture}. The framework follows the two major operations from the DL workflow: design and training in the EB-AI Workbench and inference. The Interfaces allow for flexibility with respect to the core AI libraries, edge device hardware and type of application deployment wrapper.}
		\label{fig:eb_ai_simplified_architecture}
	\end{center}

\end{figure}

\begin{comment}
\begin{figure*}
    \centering
        \subfloat[DNN accuracy.
        \label{fig:accuracy}]{\includegraphics[width=4.9cm]{figs/accuracy4_}}\hfill
        \subfloat[Comparison
        for training an epoch of MLP.\label{fig:time-mlp}]{\includegraphics[width=6.0cm]{figs/time-mlp_}}\hfill
        \subfloat[Comparison
        for training an epoch of CNN.\label{fig:time-cnn}]{\includegraphics[width=6.25cm]{figs/time-cnn_}}\hfill
    \caption{\textbf{Accuracy and performance evaluation of two types of DNNs}. The MLP has 2 hidden layers of 800 units each, followed by a softmax output layer of 10 units with 20\% dropout to input data and 50\% dropout to both hidden layers. The CNN has 2 convolutional layers with 32 kernels of size 5x5 strided and padded, a fully-connected layer of 256 units with 50\% dropout on its inputs and a 10-unit output layer with 50\% dropout on its inputs.}
    \label{fig:acc_perf}
	\vspace{-1.5em}
\end{figure*}
\end{comment}

The EB-AI cloud architecture is depicted in Fig.~\ref{fig:eb_ai_simplified_architecture}. It is based on two main components: \textit{i}) the \textit{EB-AI Workbench} and \textit{ii}) the \textit{Inference Engines}. The former generates and trains AI models, while the latter uses such models for prediction and inference on different embedded ECUs.

Specifically, the EB-AI Workbench is responsible for prototyping, training, and development of the AI models and is composed of four main modules: \textit{i}) \textit{Data Processor}, \textit{ii}) \textit{DNN Manager}, \textit{iii}) \textit{Resource Manager} and \textit{iv}) \textit{Toolbox}.

\smallskip
\noindent{\textbf{Data Processor.}} It reads, pre-processes and analyzes the data provided by the vehicles' sensors. Data pre-processing typically deals with detecting outliers in the input data, visualizing it using feature space reduction techniques such as PCA (Principal Components Analysis) and t-SNE (t-distributed Stochastic Neighbor Embedding), checking its variance and standard deviation across its data distribution domain, splitting it into appropriate train-evaluation-test batches and finally normalizing it. The probable capacity of the DNN model is determined based on the quantity of training samples. Furthermore, this stage is used to generate synthetic data through our patented GOL algorithm~\cite{grigorescu2018generative}. This allows to learn patterns of real data and generate artificial samples to improve the data available when training the DNN.

\smallskip
\noindent{\textbf{DNN Manager.}}
It contains two modules: the \textit{DNN Config Manager} handles the configuration of the DNN, while the \textit{DNN Training Coordinator} (TC) manages the training process. Similar to the work in~\cite{Villalonga_2020}, DNN models are automatically configured based on the results obtained from pre-processing the training data. By analyzing the structure and type of input data, the DNN Config Manager automatically determines the input and output shapes of the DNN architecture, thus enabling the usage of existing network architectures from the workbench.
The first step is to automatically define the input and output layers of the model based on the input-output data types. The input layer's shape is given by the structure of the training samples (e.g. images, LiDAR, radar, ultrasonic and IMU measurements, log traces, GPS tracks, etc.), while the output layer's shape is computed based on the labels' type. For example, if the training data is composed of image samples and 2D bounding boxes, then different network architecture for spatial object recognition are suggested, as shown in use-case~\ref{sec:use_cases_env_percep}. Similarly, as presented in subsection~\ref{sec:mpp}, different RNN architectures are proposed if the data is structured as temporal sequences. In this first step, training samples and labels are aggregated into single input and output layers, respectively. The automatic configuration of the input-output layers can be manually tuned if the samples and labels are composed of multiple types of sensory measurements (e.g. images and LiDAR) and/or multiple prediction heads (e.g. 2D object detection and 3D object reconstruction).

\noindent Once the input-output shapes of the DNN model have been defined, we proceed to computing the architecture of the inner layers. We split the anatomy of a DNN architecture into three main blocks: \textit{i}) backbone model, \textit{ii}) feature extractor model and \textit{iii}) prediction heads. These are chosen from subsets of state-of-the-art DNN architectures, such as VGG16, MobileNetV2 and Darknet for the backbone, or YoloV3-V5, RetinaNet and SSD (Single Shot Detector) for the case of prediction heads in object detection. We compute the DNN structure depending on the model capacity determined at Data Processor stage. Namely, in order to avoid overfitting if training data is scarce, we use a light-weighted backbone, such as VGG16, coupled to prediction heads having a lower number of convolutional layers. Different DNN models are suggested based on this analysis. The models are subsequently adapted and modified in our SiL and HiL paradigm for obtaining an optimal AI Inference Engine for the task at hand.

\noindent The TC employs libraries for DL on top of a Distributed Stream Processing System (dSPS), allowing us to run a distributed \textit{training application} on the dSPS. {\newcolor{blue}Such an application} is represented as a directed acyclic graph, where vertices represent \textit{operators} and edges represent streams between pairs of operators. Each operator carries out a piece of the overall computation, that is a \textit{training task}, and can be distributed over multiple instances.

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale=0.5]{training-task-dsps}
		\caption{\textbf{Training Tasks Operators of the dSPS}. In this example we show an instance where data managed by the operator \textit{A} is sensitive, thus the RM deploys operator instances \textit{a1} and \textit{a2} only on the two edge nodes. Operator \textit{B} can instead be performed in the Cloud, while Operator \textit{C}, which produces the AI Inference Engine, is available on all nodes.}
		\label{fig:training-task-dsps}
	\end{center}

\end{figure}

\smallskip
\noindent{\textbf{Resource Manager.}}
It {\newcolor{blue}is the elastic manager that dynamically} handles the deployment of the DNN training tasks over cloud and edge resources.
Fig.~\ref{fig:training-task-dsps} shows an example of training tasks for a dSPS application composed of four operators (A, B, C, D) allocated over the cloud and two edge nodes.

The Resource Manager (RM) is able to reconfigure over time \textit{i}) the number of edge/cloud resources, \textit{ii}) the operators' parallelism and \textit{iii}) the allocation of operator instances to available resources. Thus, RM can redistribute dynamically the training tasks on a different pool of resources to keep desired performances according to the input workload (e.g. the input rate of values read by the vehicles). The operators of the dSPS application can be distributed among edge and cloud nodes according to how {\newcolor{blue}much} resources are necessary for tasks, as well as according to the sensitivity of the acquired training data, ensuring that sensitive data is processed where it is produced, without propagating it to other cloud or edge nodes, thus mitigating privacy.
Once the learning is completed, the trained model is replicated among all edge and cloud nodes so that vehicles can immediately have the latest version available.

\smallskip
\noindent{\textbf{Toolbox.}}
It is a set of components specific for automotive AI applications. The training itself feeds the previously defined data to the network, allowing it to learn a new capability by reinforcing correct predictions and correcting the wrong ones. The module \textit{Driving Context Understanding} classifies the driving context from grid-fusion information, the \textit{Behavior Arbitration} understands the driving context and optimizes the strategy from real-world grid representations, while the \textit{Driving Simulation Environment} trains, evaluates and tests AI algorithms in a virtual simulator, such as Microsoft's AirSim.

\smallskip
\noindent{\textbf{Inference Engine.}}
It contains the trained AI models from the EB-AI Workbench and deployment wrappers (or application) for the models. For example, such a wrapper can be built as a Robotic Operating System (ROS) Node~\footnote{ROS --- \url{https://www.ros.org/}}, or an EB Assist ADTF$^{\circledR}$ component. ADTF stands for \textit{Automotive Data and Time-Triggered Framework}~\footnote{ADTF --- \url{https://www.elektrobit.com/products/automated-driving/eb-assist/adtf/}} and is a tool for the development, validation, visualization and testing of advanced driver assistance systems and automated driving features.

\smallskip
\noindent{\textbf{Interfaces.}}
Both EB-AI Workbench and Inference Engine use an interface layer for low-level libraries (e.g. CUDA, Tensorflow, PyThorch, CNTK, or Caffe2), integration with the dSPS engine (e.g. Spark) and the APIs for cloud and edge nodes. Furthermore, it provides a specific interface to ADTF and ROS.

\section{Conclusions}
\label{sec:conclusions}

In this paper, we have proposed an elastic AI development framework for autonomous driving applications based on deep learning, which takes into account some of the advances brought about by AI, Cloud and Edge computing. A modular Elastic toolchain providing all the required DL components enables the deployment of training tasks over both Cloud end Edge resources, where the latter can be located on the vehicles themselves. Pre-processing raw data and/or training partial models at the Edge allows to reduce the amount of data to upload to the Cloud and help mitigate privacy issues. We showed the effectiveness of the proposed toolchain in two application cases implemented at Elektrobit Automotive, namely Environment Perception and Most Probable Path Prediction. Furthermore, we showed the convenience of exploiting a distributed setting to parallelize as much as possible the training of the DNNs.

As future work, we aim to prototype and deploy AI Inference Engines at a large scale using the proposed hybrid deployment strategy over a larger fleet of autonomous vehicles.

\section{Hybrid Deployment Advantages}
\label{sec:cloud_edge}

This section discusses the advantages brought by the proposed hybrid deployment. Specifically, it discusses how our solution preserves privacy (Section~\ref{sec:privacy}) and how it improves fault tolerance and scalability (Section~\ref{sec:hybrid}). In Appendix \ref{appendixA} we also provide an experimental evaluation aimed to show the benefit of increases parallelism in DNN training.

\subsection{Privacy-preserving Techniques}
\label{sec:privacy}

Although the Cloud can offer a scalable training infrastructure, some training data should not flow to the Cloud due to data protection requirements, as those on personal data enforced by the GDPR. Both data encryption and obfuscation solutions can be used to address these challenges.

Data obfuscation techniques like Differential Privacy (DP) have been successfully used both in centralized and federated learning~\cite{3324405}. Differently from pre-processing techniques, using DP on Edge devices as part of a federated learning approach guarantees better accuracy~\cite{HuangMFLG17,YangLCT19}. In particular, Edge devices are carrying out the training of a number of front layers by using DP on the sensitive data. Then, they transmit the intermediate results to the Cloud for the completion of the training and dissemination to the Edge of the updated layers.

Learning on encrypted data has also been proposed. While homomorphic encryption has been prototyped on centralized Cloud training~\cite{6410315}, applications of Multi Party Computation (MPC) offers distributed privacy-preserving training~\cite{7958569}.

The EB-AI toolchain supports DP learning by relying on the TensorFlow Privacy library\footnote{TensorFlow Privacy --- \url{https://github.com/tensorflow/privacy}}. Differently from MPC learning that must rely on ad-hoc computing framework (e.g. Sharemind~\cite{Bogdanov:2008}), DP learning can be managed by the EB-AI framework to take advantage of Edge devices on self-driving cars.
The TensorFlow Privacy library relies on a differentially private stochastic gradient descent (SGD) algorithm~\cite{abadi2016deep}, which provides privacy protection for deep neural networks while incurring a tolerable overhead in terms of training time.

{\newcolor{blue}
\subsection{Fault Tolerance and Elastic Scalability}
\label{sec:hybrid}
}
The EB-AI architecture can support flexible learning deployment across Cloud and Edge, offering scalable execution of learning tasks according to resource and privacy constraints.

Despite the advances in OTA software, the deployment of learning tasks must tolerate faults due to lack of connectivity with AVs.
Distributed computing frameworks, such as Apache Spark, can be deployed to enable {\newcolor{blue}elastic} fault tolerant federated learning via, for example, TensorSpark and CaffeOnSpark.

{\newcolor{blue}
The EB-AI Resource Manager extends the ELYSIUM~\cite{lombardi2017elastic} autoscaler in order to
}
rebalance the operators of the training application. {\newcolor{blue} Specifically, it elastically scales both the dSPS operators' parallelism and resources (cloud and edge nodes), allocating these operators according to workload changes or faults predicted and/or observed.}

The flexibility of the task definition provided by existing dSPS platforms, together with their seamless integration with high-level AI frameworks, allows the EB-AI workbench to directly introduce new pre-processing or pre-training tasks at the Edge according to emerging privacy and learning constraints.

\section{Explainability and Safety}
\label{sec:safety}

	Nowadays developing algorithms that solve problems no matter what side effects can arise has became unacceptable. An algorithm that cannot explain it's decisions is useless in safety critical systems. Likewise using data that is private leads to the impossibility to deploy the algorithm to public use. Through this chapter we go over the solutions that the AI-tooling adopted in order to cope with these kind of limitations.

	\subsection{Explainability and Safety}
	\label{sec:explainability}

	Black-box algorithms such as deep neural networks started to be used more and more in complex systems to make important decisions. The necessity to interpret and to explain the neural network decisions became mandatory. This necessity lead to a totally new line of research that aims at creating explanatory neural networks \cite{Gilpin2018}. In order to comprehend what a model did the user shall be able to visually observe cues from the different layers of the network to find the \emph{attention} that determined to take a certain decision. This task is not trivial especially for the neural networks that have complex outputs. In this situation, the solution is to create a proxy model that behaves similarly to the original one, or to create a salience map to emphasise the part of the computation that was most relevant.

	The concept is mainly based on two elements: \textit{interpretability} and \textit{explainability}. Interpretability represents the possibility of describing the internals of the system(network) in a way that is understandable to a human. Explainability represents the understanding of how the data was processed or represented inside the network. The question to which the explainability must respond is: \emph{Why this particular input lead to that particular output?}. The success of the interpretability is subjective and is tied to the experience of the user while the success of the explainability is mainly based on the design of the neural network. A neural network that can explain it's decision can also asses hazard and risk analysis which further enables the system to comply to the ISO 26262 standard. This may be one solution that enables functional safety of neural networks acting in human life systems \cite{Rick_Salay2017}.

	Within the AI-Tooling framework the interpretability is addressed as the possibility of the user to observe the activations of the different layers of the neural network architecture. Since this process imply interaction with the user the visualization of the activations is possible only for the test samples. During training such interaction would have been time consuming and less relevant because of the changing weights. The common scenario that the user must follow to interpret the decision made by the network is the following. Using the AI-Tooling the user trains and tests a neural network. From the statistics window of the results menu the user can select a particular sample. Further, the work-flow guides the user to the network configuration window where the architecture is plotted. Here the user can click on the layers in order to visualize the activations. Figure ~\ref{fig:eb_ai_explainability_diagram} presents a reduced version of a traffic scene segmentation network (left column) along with the activations that lead to the final decisions (right column).

	\begin{figure}[t]
		\centering
		\begin{center}
			\includegraphics[scale= 1.2]{Explainability_diagram.png}
			\caption{\textbf{Following the decision of a segmentation use case.} First column presents the network architecture. Second column presents the activations of different layers from the network.}
			\label{fig:eb_ai_explainability_diagram}
		\end{center}
	\end{figure}

	The tool is able to compute the activations only for common layers like convolutional, normalization, dense, un-sampling, maxPool, flatten or reshape. Layers like LSTM or lambda are difficult to represent in a human readable and thus not appropriate to interpret.

	In very simple neural network looking into the activations and explaining what lead to the final decision may be easy possible. Nevertheless the explainability is not that straight forward in networks with thousand or millions of parameters. The solution is to reduce the number of the parameters or to focus only on the most important parts from the network for each problem. The AI-tooling framework approaches this problem by creating a \emph{salience map} or \emph{heat map} to highlight the parts of the computation that are the most relevant for the final decision \cite{Shrikumar2017}, \cite{Simonyan2013}. Figure ~\ref{fig:eb_ai_explainability_heatmap} presents a heat-map describing what parts from the image contributed most to segment the vehicles from a traffic scene. The areas with high network activation (orange-red) shows where the neurons fire strongest. From the heat-map the safety system determines if the attention of the neural network was correctly channelled and thus the output is valid.

	\begin{figure}[t]
		\centering
		\begin{center}
			\includegraphics[scale= 0.08]{heatmap_vehicle.jpg}
			\caption{\textbf{Heatmap} visualization of the learned weights for class vehicle from the first layer. Red is depicting pixels from the image that fired strongest.}
			\label{fig:eb_ai_explainability_heatmap}
		\end{center}
	\end{figure}

\section{Introduction}
\label{sec:introduction}

Among the new technological trends arisen in the last decade, \textit{Autonomous Driving} has gained a lot of attention, with significant effort and resources invested by both academia and enterprises. The breakthroughs in self-driving cars has been made possible by the emergence of novel algorithms and real-time computing systems in the field of Artificial Intelligence (AI), Deep Learning (DL), Internet-of-Things (IoT) and Cloud computing~\cite{Grigorescu_JFR_2020}.

An Autonomous Vehicle (AV) is an intelligent agent which observes its environment, makes decisions and performs actions based on these decisions. Autonomous driving applications aim to enable vehicles to automatically control their behavior. Traditionally in classical cars, these aspects and functionalities are the exclusive responsibility of human drivers, including understanding of the driving scene, path prediction, behavioral planning and control. The development and deployment of accurate AI models which can automatize these tasks is fundamental to support the progress of autonomous driving. Addressing these challenges lies within the realms of \textit{Data Science}, with AI and DL proving to be successful tools to generate sufficiently accurate representations of real-world processes. Deep Learning (DL) and Deep Neural Networks (DNN) have become leading technologies in many domains, enabling vehicles to perceive their driving environment and take actions accordingly. Although several cloud-based solutions have been proposed for the automatic reconfiguration and adaptation of distributed platforms in Industry 4.0~\cite{Villalonga_2020}, automotive grade systems have been scarcely reported.

Nowadays, numerous software tools are available, providing solutions for each particular stage in the development of an AI-based application. A key benefit for a driving function engineer is to have a comprehensive framework for enabling both the prototyping of the AI components, as well as their deployment and evaluation on target Edge devices such as Electronic Control Units (ECUs). General AI tooling systems such as MATLAB~\cite{Matlab2018}, Amazon Web Services (AWS)~\cite{AVS2020} or AI-One~\cite{AIONE2020} provide functionalities to enable users to design and integrate custom AI modules. However, these tooling systems are neither tailored for the automotive sector, nor for the specificity of the autonomous driving applications. One of the major drawbacks is their lack of alignment to the automotive functional safety standard ISO26262~\cite{Salay2017}, particularly to ASIL (Automotive Safety Integrity Level) hierarchy. On the other hand, major automotive and chip manufacturing companies are developing their own in-house AI frameworks, such as Tesla's \textit{Full Self-Driving} and \textit{Dojo} computers~\footnote{Tesla's Dojo --- \url{https://syncedreview.com/2020/08/19/tesla-video-data-processing-supercomputer-dojo-building-a-4d-system-aiming-at-l5-self-driving/}}, NVDIA's \textit{DriveWorks} platform~\footnote{NVIDIA DriveWorks --- \url{https://developer.nvidia.com/drive/driveworks}}, or Uber's Michelangelo training framework~\footnote{Uber's Michelangelo --- \url{https://eng.uber.com/michelangelo-machine-learning-platform/}}. The problem with these tooling systems is that they are either designed to be used solely by the developing company (e.g. Tesla, Uber, etc.), or are build to operate only on specific hardware, as in the case of NVIDIA's AI solutions.

In this paper, we first analyze the development process of AI-based autonomous driving applications and identify its current limitations. Secondly, we propose the \emph{Coud2Edge Elastic EB-AI Framework} as a revised prototyping and deployment workflow for building AI based solutions for autonomous driving. We introduce the novel concept of \textit{AI Inference Engine}, which encompasses a simple yet elegant solution to the training, evaluation and deployment of AI-based components for self-driving cars. Throughout the paper, we refer to a real scenario, where autonomous driving applications are developed at Elektrobit (EB) Automotive~\footnote{Elektrobit Automotive --- \url{https://www.elektrobit.com/}}, a world-wide supplier of embedded and connected software products and services for the automotive industry.

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale=0.47]{eb_ai_inference_engine.png}
		\caption{\textbf{AI Inference Engine concept}. Deep Learning based inference engine evaluated at prototyping level within the Cloud as Software-in-the-Loop (SiL), as well as on the targeted edge device ECU, as Hardware-in-the-Loop (HiL).}
		\label{fig:inference_engine_workflow}
	\end{center}
	\vspace{-2.2em}
\end{figure}

\subsection{The EB-AI Framework}

The key differences of the EB-AI framework provides with respect to tooling systems such as the ones listed above are:

\begin{itemize}
	\item ability to digest automotive specific input data such as video streams, LiDAR and/or Radar data;
	\item prototyping and development of AI Inference Engines in the Cloud using a SiL paradigm, agnostic of low-level AI libraries such as TensorFlow~\cite{abadi2016tensorflow}, PyTorch~\cite{paszke2017automatic}, or Caffe~\cite{Caffe};
	\item providing tunable state of the art DNN architectures for a broad spectrum of autonomous driving applications;
	\item ability to deploy and evaluate the obtained AI Inference Engines via HiL testing on edge devices (e.g. target ECUs).
\end{itemize}

The diagram in Fig.~\ref{fig:inference_engine_workflow} illustrates the development workflow of an AI Inference Engine based on the EB-AI framework, according to our own data driven V-Model detailed in Section~\ref{sec:architecture}. Once the specific problem to solve has been defined and enough data has been collected, that data is ingested at prototyping level by a DNN which stands at the core of the inference engine. During this stage, the DNN is trained, evaluated and refined within the Cloud according to the Software-in-the-Loop (SiL) principles. Finally, the inference engine is deployed on a target Edge device inside a vehicle and evaluated again in real-world scenarios as Hardware-in-the-Loop (HiL). This process allows us to refine the engine even further, according to a continuous feedback loop aimed to keep improving applications over their entire life span. The novelty of the AI Inference Engine concept lies in the effective integration of the DNN's training, evaluation as SiL and testing using the HiL paradigm.

A key aspect to consider in the EB-AI workflow is the huge amount of data required to train DNNs. This data can be either synthetically generated (first stage) or collected via real sensors mounted on test vehicles (last stage). In both cases, the data has to be made available at training stage. Although the training of DNNs can be highly parallelized~\cite{batiz2012parallelizing}, with unprecedented levels of parallelization reached by leveraging the recent wide availability of GPUs, it is still prohibitive to have enough computational power to process the amount of data required by autonomous driving applications. As a consequence, all Cloud computing providers offer commoditized AI solutions (e.g., IBM's Watson AI, Amazon AI, Microsoft's Azure AI and Google's Cloud AI) for scalable computing training facilities. However, the following limitations hold at AI Inference Engine prototyping stage, when large quantities of data have to be uploaded to the Cloud: \textit{i}) data upload impracticality due to bandwidth bottlenecks and latency~\cite{Nangare2018}, \textit{ii}) difficult enforcement of privacy requirements (e.g. GDPR~\cite{Wiles2018}), since part of the collected raw data can be sensitive and thus cannot be shared with cloud providers.

\subsection{Contributions}

We propose a solution to overcome the presented limitations by exploiting recent developments in Over-The-Air (OTA) systems for AVs~\cite{greenough2016connected, khurram2016enhancing}, enabling the use of an AV as an additional computational device. These computing resources localized on the Edge ECUs, also referred to as \emph{Edge computing}, can be integrated with Cloud resources to provide an \textit{Elastic} distributed infrastructure in which the training can be collaboratively carried out~\cite{HuangMFLG17,8270639}. Furthermore, Edge devices can limit the data transmitted to the Cloud by pre-processing local raw data or pre-training partial models~\cite{8487352}, which in turn can also help mitigate privacy concerns, since raw data sharing can be directly avoided. This kind of hybrid deployment over the Cloud and Edge resources calls for a modular framework for AI-based autonomous driving applications. To this aim, the proposes EB-AI architecture provides a modular toolchain that enables the deployment of autonomous driving applications across Edge and Cloud resources.

Therefore, the main contributions of the paper are:

\begin{itemize}
	\item a simple yet elegant AI Inference Engine concept, based on the SiL and HiL principles;
	\item a data-driven V-Model approach guiding the design of AI-based autonomous driving applications;
	\item a modular Cloud2Edge AI framework for autonomous driving applications coined EB-AI;
	\item an Elastic framework able to overcome network bandwidth and privacy concerns by dynamically deploying deep learning training tasks among Edge and Cloud;
	\item the development of two real-world AI Inference Engines for \textit{environment perception} and \textit{most probable path prediction};
	\item a discussion on the advantages of such a hybrid deployment, in terms of training parallelization, privacy-preservation, fault tolerance and scalability.
\end{itemize}

\smallskip
\noindent
\emph{Structure of the Paper.}
Section~\ref{sec:related_work} reports most relevant background concepts and related work. Section~\ref{sec:architecture} presents the V-Model approach and the proposed EB-AI framework. Section~\ref{sec:cloud_edge} discusses the deployment of the architecture across Cloud and Edge devices. Finally, two relevant AI Inference Engines are detailed in Section~\ref{sec:use_cases}, while the conclusions are stated in Section~\ref{sec:conclusions}.

\section{Introduction}
\label{sec:introduction}

Among the new technological trends arisen in the last decade, \textit{Autonomous Driving} has gained a lot of attention, with significant effort and resources invested by both academia and enterprises. The breakthroughs in self-driving cars has been made possible by the emergence of novel algorithms and real-time computing systems in the field of Artificial Intelligence (AI), Deep Learning (DL), Internet-of-Things (IoT) and Cloud computing~\cite{Grigorescu_JFR_2020}.

An Autonomous Vehicle (AV) is an intelligent agent which observes its environment, makes decisions and performs actions based on these decisions. Autonomous driving applications aim to enable vehicles to automatically control their behavior. Traditionally in classical cars, these aspects and functionalities are the exclusive responsibility of human drivers, including understanding of the driving scene, path prediction, behavioral planning and control. The development and deployment of accurate AI models which can automatize these tasks is fundamental to support the progress of autonomous driving. Addressing these challenges lies within the realms of \textit{Data Science}, with AI and DL proving to be successful tools to generate sufficiently accurate representations of real-world processes. Deep Learning (DL) and Deep Neural Networks (DNN) have become leading technologies in many domains, enabling vehicles to perceive their driving environment and take actions accordingly. \textcolor{red}{Although several cloud-based solutions have been proposed for the automatic reconfiguration and adaptation of distributed platforms in Industry 4.0~\cite{Villalonga_2020}, automotive grade systems have been scarcely reported.}\todo{Added paragraph and reference to Cloud-based systems for data driven reasoning in industry 4.0.}

Nowadays, numerous software tools are available, providing solutions for each particular stage in the development of an AI-based application. A key benefit for a driving function engineer is to have a comprehensive framework for enabling both the prototyping of the AI components, as well as their deployment and evaluation on target Edge devices such as Electronic Control Units (ECUs). General AI tooling systems such as MATLAB~\cite{Matlab2018}, Amazon Web Services (AWS)~\cite{AVS2020} or AI-One~\cite{AIONE2020} provide functionalities to enable users to design and integrate custom AI modules. However, these tooling systems are neither tailored for the automotive sector, nor for the specificity of the autonomous driving applications. One of the major drawbacks is their lack of alignment to the automotive functional safety standard ISO26262~\cite{Salay2017}, particularly to ASIL (Automotive Safety Integrity Level) hierarchy. On the other hand, major automotive and chip manufacturing companies are developing their own in-house AI frameworks, such as Tesla's \textit{Full Self-Driving} and \textit{Dojo} computers~\footnote{Tesla's Dojo \url{https://syncedreview.com/2020/08/19/tesla-video-data-processing-supercomputer-dojo-building-a-4d-system-aiming-at-l5-self-driving/}}, NVDIA's \textit{DriveWorks} platform~\footnote{NVIDIA DriveWorks \url{https://developer.nvidia.com/drive/driveworks}}, or Uber's Michelangelo training framework~\footnote{Uber's Michelangelo \url{https://eng.uber.com/michelangelo-machine-learning-platform/}}. The problem with these tooling systems is that they are either designed to be used solely by the developing company (e.g. Tesla, Uber, etc.), or are build to operate only on specific hardware, as in the case of NVIDIA's AI solutions.

In this paper, we first analyze the development process of AI-based autonomous driving applications and identify its current limitations. Secondly, we propose the \emph{Coud2Edge Elastic EB-AI Framework} as a revised prototyping and deployment workflow for building AI based solutions for autonomous driving. We introduce the novel concept of \textit{AI Inference Engine}, which encompasses a simple yet elegant solution to the training, evaluation and deployment of AI-based components for self-driving cars. Throughout the paper, we refer to a real scenario, where autonomous driving applications are developed at Elektrobit (EB) Automotive~\footnote{Elektrobit Automotive \url{https://www.elektrobit.com/}}, a world-wide supplier of embedded and connected software products and services for the automotive industry.

The key improvements that the EB-AI framework provides with respect to tooling systems such as the ones listed above are:

\begin{itemize}
	\item ability to digest automotive specific input data such as video streams, LiDAR and/or Radar data;
	\item prototyping and development of AI Inference Engines in the Cloud using a SiL paradigm, agnostic of low-level AI libraries such as TensorFlow~\cite{abadi2016tensorflow}, PyTorch~\cite{paszke2017automatic}, or Caffe~\cite{Caffe};
	\item providing tunable state of the art DNN architectures for a broad spectrum of autonomous driving applications;
	\item ability to deploy and evaluate the obtained AI Inference Engines via HiL testing on edge devices (e.g. target ECUs).
\end{itemize}

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale=0.47]{eb_ai_inference_engine.png}
		\caption{\textbf{AI Inference Engine concept}. Deep Learning based inference engine evaluated at prototyping level within the Cloud as Software-in-the-Loop (SiL), as well as on the targeted edge device ECU, as Hardware-in-the-Loop (HiL).}
		\label{fig:inference_engine_workflow}
	\end{center}
	\vspace{-2.2em}
\end{figure}

The general principal for the development of an AI Inference Engine is shown in Fig.~\ref{fig:inference_engine_workflow}, according to our own data driven V-Model workflow detailed in Section~\ref{sec:architecture}. Once the specific problem to solve has been defined and enough data has been collected, that data is ingested at prototyping level by a DNN which stands at the core of the inference engine. During this stage, the DNN is trained, evaluated and refined within the Cloud according to the Software-in-the-Loop (SiL) principles. Finally, the inference engine is deployed on a target Edge device inside a vehicle and evaluated again in real-world scenarios as Hardware-in-the-Loop (HiL). This process allows us to refine the engine even further, according to a continuous feedback loop aimed to keep improving applications over their entire life span. The novelty of the AI Inference Engine concept lies in the effective integration of the DNN's training, evaluation as SiL and testing using the HiL paradigm.

A key aspect to consider in the EB-AI workflow is the huge amount of data required to train DNNs. This data can be either synthetically generated (first stage) or collected via real sensors mounted on test vehicles (last stage). In both cases, the data has to be made available at training stage. Although the training of DNNs can be highly parallelized~\cite{batiz2012parallelizing}, with unprecedented levels of parallelization reached by leveraging the recent wide availability of GPUs, it is still prohibitive to have enough computational power to process the amount of data required by autonomous driving applications. As a consequence, all Cloud computing providers offer commoditized AI solutions (e.g., IBM's Watson AI, Amazon AI, Microsoft's Azure AI and Google's Cloud AI) for scalable computing training facilities. However, the following limitations hold at AI Inference Engine prototyping stage, when large quantities of data have to be uploaded to the Cloud: \textit{i}) data upload impracticality due to bandwidth bottlenecks and latency~\cite{Nangare2018}, \textit{ii}) difficult enforcement of privacy requirements (e.g. GDPR~\cite{Wiles2018}), since part of the collected raw data can be sensitive and thus cannot be shared with cloud providers.

We propose a solution to overcome these limitations by exploiting recent developments in Over-The-Air (OTA) systems for AVs~\cite{greenough2016connected, khurram2016enhancing}, enabling the use of an AV as an additional computational device. These computing resources localized on the Edge ECUs, also referred to as \emph{Edge computing}, can be integrated with Cloud resources to provide an \textit{Elastic} distributed infrastructure in which the training can be collaboratively carried out~\cite{HuangMFLG17,8270639}. Furthermore, Edge devices can limit the data transmitted to the Cloud by pre-processing local raw data or pre-training partial models~\cite{8487352}, which in turn can also help mitigate privacy concerns, since raw data sharing can be directly avoided. This kind of hybrid deployment over the Cloud and Edge resources calls for a modular framework for AI-based autonomous driving applications. To this aim, the proposes EB-AI architecture provides a modular toolchain that enables the deployment of autonomous driving applications across Edge and Cloud resources. The main contributions of the paper are:

\begin{itemize}
	\item a simple yet elegant AI Inference Engine concept, based on the SiL and HiL principles;
	\item a data-driven V-Model approach guiding the design of AI-based autonomous driving applications;
	\item a modular Cloud2Edge AI framework for autonomous driving applications coined EB-AI;
	\item an Elastic framework able to overcome network bandwidth and privacy concerns by dynamically deploying deep learning training tasks among Edge and Cloud;
	\item the development of two real-world AI Inference Engines for \textit{environment perception} and \textit{most probable path prediction};
	\item a discussion on the advantages of such a hybrid deployment, in terms of training parallelization, privacy-preservation, fault tolerance and scalability.
\end{itemize}

\noindent
The rest of the paper is organized as follows. Section~\ref{sec:related_work} reports most relevant background concepts and related work. Section~\ref{sec:architecture} presents the V-Model approach and the proposed EB-AI framework. Section~\ref{sec:cloud_edge} discusses the deployment of the architecture across Cloud and Edge devices. Finally, two relevant AI Inference Engines are detailed in Section~\ref{sec:use_cases}, while the conclusions are stated in Section~\ref{sec:conclusions}.

\section{Background and Related Work}
	\label{sec:related_work}

In the following, we overview the main concepts of DL, report on general DL tooling systems and highlighting the main limitations of available tools and learning environments for automotive applications.

\subsection{Deep Learning Overview}

\textit{Deep Learning} is a branch of machine learning which leverages on large DNN architectures to build a layered representation of the input data~\cite{bengio2013representation}. DNNs are universal non-linear function approximators, built using multiple hidden layers, and can be classified based on their architecture. \textit{Convolutional Neural Networks} (CNNs) are mainly used for processing spatial information, such as images, and can be viewed as image feature extractors. Recurrent Neural Networks (RNN) are especially good in processing temporal sequence data, such as text, or video streams. Different from conventional neural networks, an RNN contains a time dependent feedback loop in its memory cell. Due to the high number of layers, DNNs are difficult to train using vanilla backpropagation algorithms. As an example, in the case of auto-encoders~\cite{hinton1994autoencoders}, each layer is trained separately, then backpropagation is used to train the whole network. To avoid overfitting (i.e. trained models that cannot generalize or predict unseen values), common methods such as Dropout~\cite{srivastava2014dropout} are used to regularize the training.

DNNs are effective in domains characterized by a high number of features, such as computer vision and natural language processing. Training of DNNs critically requires large annotated datasets which have been increasingly released in the last decade, especially in the computer vision field. One of the first large collection of annotated images is the ImageNet database~\cite{ImageNet_ILSVRC15}, which contains $1.5$ mil images representing $1000$ object classes in a variety of shapes, poses and illumination conditions. Although images relevant to autonomous driving systems are only a subset of the whole collection, the complete database were used to pre-train the first convolutional layers of object detectors used for driving scene perception~\cite{Grigorescu_JFR_2020}.

In the last years, mainly due to the increasing research interest in autonomous vehicles, many driving datasets were made public. These vary in size, sensory setup and data format, commonly comprising of synchronized ego-data, video, LiDAR, Radar, ultrasonic, inertial measurements and GPS datastreams. Among others, popular ones are the KITTI Vision Benchmark dataset (KITTI)~\cite{KITTI2013} by the Karlsruhe Institute of Technology (KIT), NuScenes~\cite{nuscenes2019} by Aptive, or Cityscapes~\cite{Cityscapes2018} by Daimler, Max Planck Institute and TU Darmstadt.

Since acquiring large training datasets is a demanding process, usually performed via manual annotation, alternative methods have been explored for synthetic data generation and simulation engines. In our previous work we have proposed and patented a semi-parametric approach to one-shot learning, coined \emph{Generative One-Shot Learning} (GOL)~\cite{grigorescu2018generative}. Given as input single one-shot objects (or generic patterns and templates), together with a small set of regularization samples, GOL  uses the sample to drive the generative process by outputting new synthetic data. Specifically, it permits to generalize on unseen data, while increasing the classification accuracy on synthetic data as much as possible.

\subsection{Deep Learning Libraries and Tools}

Some of the well-established low-level AI libraries are Tensorflow~\cite{abadi2016tensorflow} by Google, PyThorch~\cite{paszke2017automatic} by Facebook, the Cognitive Neural ToolKit (CNTK)\footnote{CNTK --- \url{https://docs.microsoft.com/en-us/cognitive-toolkit/}} by Microsoft, and Caffe2~\cite{Caffe} from Berkeley University. The APIs are mainly available for C/C++ and Python  languages, although other notable implementations exists, such as Weka~\cite{hall2009weka} which is written in Java. For facilitating their usage and large scale adoption, these libraries are integrated into high-level frameworks (e.g. Lasagne\footnote{Lasagne --- \url{http://lasagne.readthedocs.org/en/latest/}}).

For fast computation, training commonly takes place on GPUs interconnected as clusters, which are available as a service on the major Cloud platforms, e.g. Microsoft Azure and Amazon AWS. After training, the DNN models are downloaded into edge devices for inference. In this case, edge devices can be smartphones, PC commuters, or target ECU devices part of automotive applications.

In order to exploit parallel computation, the training can be distributed based on data partition (e.g. among threads, different machines,  GPUs, etc.) or  model partition~\cite{xing2016strategies}. Scalable deployments are enabled by distributed computing platforms such as Storm~\cite{toshniwal2014storm} and Spark~\cite{zaharia2010spark}. In particular, \mbox{Trident-ML}\footnote{Trident-ML --- \url{https://github.com/pmerienne/trident-ml}} is a real-time library for machine learning upon Storm, while CaffeOnSpark~\cite{noel2016large} and TensorSpark~\cite{tensorspark} are Spark integrations of Caffe and TensorFlow, respectively.

To overcome bandwidth and privacy issues when uploading data to the Cloud, federated learning~\cite{YangLCT19} offers a technical framework to scale learning horizontally or vertically across devices~\cite{KonecnyMRR16}. Edge computing is therefore exploited to carry out pre-training, whose results are integrated on the Cloud and then offloaded on the Edge for on-device inference~\cite{8681645}.

The above mentioned frameworks are designed solely for training purposes within the Cloud. In comparison, the main advantage of EB-AI over them is our proposed Elastic approach, which considers both training and inference as a joint task distributed onto powerful GPU clusters residing in the Cloud and Edge computing devices available in each autonomous vehicle belonging to a connected fleet of cars. Additionally, as opposed to the more general AI frameworks presented in this subsection, EB-AI has been designed specifically for automotive purposes, following the constraints of Automotive SPICE and the ISO26262~\cite{Salay2017} functional safety standard, along with a proposed data driven V-Model for building AI Inference Engines.

\subsection{AI Frameworks in Autonomous Driving}

The application of deep learning, and more general of AI, to the automotive industry has grown significantly in the last few years. AI and Deep Learning are used to obtain human-like behaviors in automated driving~\cite{luckow2016deep}, such as environment perception and scene understanding (e.g. detecting traffic signs, traffic participants, road obstacles, etc.), or trajectory planning and control. Deploying AI Inference Engines inside autonomous vehicles requires overcoming limitations of platform dependencies and limited computation resources. Therefore, new transportation vehicles are equipped with embedded ECU devices specialized for AI and exploited to ensure adequate performance and energy efficiency~\cite{brilli2018convolutional}.

Overall, the increasing interest in AI Inference Engines for the automotive industry has been driven by the field of autonomous vehicles. While a number of AI-enabled functions are already deployed in cars and interacting with drivers~\cite{fridman2017autonomous}, it is predicted that full-fledged AVs, that is SAE levels 4 and 5~\cite{SAE}, will require significant additional cost for developing the new required AI solutions~\cite{litman2019autonomous}. As such, there is the need to optimize the design, deployment and maintenance of automotive AI Inference Engines by reducing their complexity and by improving accuracy via the access to (real-time) data. Lu et al. proposed a work close to our~\cite{234807}, where they introduced distributed learning based on self-driving cars as Edge computing devices. However, they only train local models on the cars and then aggregate the parameters of the neural network on a Parameter EdgeServer. Conversely, we propose a solution to split training tasks between cloud and edge, in order to deploy training task which process sensitive data only over the edge while deploying the other over both cloud and edge.

Car manufactures and their suppliers are both developing their own in-house AI frameworks. Example of such systems are Tesla's \textit{Full Self-Driving} and \textit{Dojo} computers, NVDIA's \textit{Drive Works} platform, or Uber's Michelangelo training framework. However, these are either closed software platforms, built for in-house operations, or are designed to work only on dedicated hardware, as in the case of NVIDIA's software solutions. Based on Elektrobit's history as a key supplier of automotive grade software and real-time operating systems, we have designed EB-AI for interoperability, incorporating optimizations of AI Inference Engines for different embedded ECU devices, coupled with the necessary functional safety standards required by the automotive industry.

\section{EB-AI Use Cases}
\label{sec:use_cases}

State of the art autonomous driving systems are defined using modular perception-planning-action pipelines, in which the main problem is divided into smaller sub-problems, each module being designed to solve a specific task and deliver the outcome as input to the adjoining component~\cite{Grigorescu_JFR_2020}.

In the following, we aim to highlight the functionalities of the proposed EB-AI framework in two autonomous driving application use-cases, namely \emph{driving environment perception} and \emph{most probable path prediction}. Since this article focus on the underlying computing framework, as opposed to a specific algorithm, we will not focus on the accuracy of the two use-case methods, but on their designed, deployment and evaluation using the proposed EB-AI framework.

In both use cases presented below, we use the proposed Elastic Cloud2Edge paradigm to perform data ingestion and the configuration of the DNNs using EB-AI's Workbench interface from Fig.~\ref{fig:EB_AI_pipeline}, while the \textit{DNN Manager} and \textit{Resource Manager}, detailed in Section~\ref{sec:architecture}, are used to jointly distribute the training on the Cloud and the AVs' Edge devices.

\subsection{Use Case 1: Driving Environment Perception}
\label{sec:use_cases_env_percep}

The perception of the driving environment is a key part of any autonomous driving system, characterized as the ability of the inference engine to understand the image scene and accurately represents the dynamic and stationary objects (e.g. cars, pedestrians, traffic signs, etc.). The EB-AI framework offers ready to use DNN architectures, such as SegNet for traffic scene image segmentation~\cite{badrinarayanan2015segnet}, different versions of the Yolo detector~\cite{RedmonYOLO2016} and our own Deep Grid Net (DGN) for driving context understanding~\cite{marina2019dgn}. For the use case of environment perception, the specific problem space of object detection in images will be considered.

\begin{figure}
	\centering
	\begin{center}
			\includegraphics[scale=1.2]{env_perception_use_case2.png}
			\caption{\textbf{Pairs of samples and labels commonly used in environment perception DNNs.} a) Input RGB image and 3D point cloud. b) Labels of objects of interest annotated in 2D on images and in 3D onto point cloud data, respectively.}
			\label{fig:env_perception}
	\end{center}
\end{figure}

For environment perception, we perform object detection and classification on RGB color images and XYZ point clouds, as illustrated in Fig.~\ref{fig:env_perception}. We used labelled data from the CamVid dataset \cite{CamVid2018}, which we have converted into the ROS bags. The ROS bags are uploaded into the EB-AI Cloud for pre-processing operations such as normalization, encoding or clipping.

Fig.~\ref{fig:EB_AI_pipeline} shows a couple of snapshots from the EB-AI Cloud interface, depicting the data upload, DNN architecture design and training as SiL, deployment and evaluation via HiL and models comparison. The first steps in building an AI inference engine is the definition of the requirements and collection of the necessary data for training. The data itself is collected from two sources, namely vehicles' sensors and synthetic generation through our GOL algorithm~\cite{grigorescu2018generative}. This allows the improvement of the patterns learned from real data and the ability of the trained network to generalize. A manual splitting ratio of the data between train, validation and test is available, as well as automatic k-fold variations.

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale=0.92]{EB_AI_pipeline.png}
		\vspace{0.5em}
		\caption{\textbf{Snapshots from the EB-AI Cloud interface.} (a) Data upload and pre-processing. (b) DNN architecture design. (c) Deployment and evaluation in the Cloud and Edge ECU as SiL and HiL, respectively. (d) Models comparison.}
		\label{fig:EB_AI_pipeline}
	\end{center}
\end{figure}

By analyzing the input data the \textit{DNN Config Manager} automatically determines the input and output shape of the DNN architecture, thus enabling the usage of existing network architectures from the workbench. Additional adjustments can be made in order to improve the accuracy of the DNN, based on the task at hand. In this driving environment perception use-case we use a Yolo V5 DNN trained on pairs of camera images and annotated 2D bounding boxes of objects of interest.

The training is managed by the \textit{DNN Training Coordinator}, which handles the DL libraries on top of a distributed streaming processing system. The Resource Manager handles the available training resources over the cloud and/or edge device. In order to illustrate the fault tolerance and scalability of the training process, we have used different ECU configurations with 8, 12 and 16 nodes respectively. The ECUs are a baseline desktop computer equipped with an Intel Core i9 9900K CPU, 64 GB RAM, with two high-performance NVIDIA GeForce RTX 2080 Ti graphics cards, an NVIDIA Jetson AGX platform, a Kalray Konic board and a RaspberryPi 3B+ computer.

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale=0.42]{scalability_fault_tolerance.png}
		\caption{\textbf{Usage of training resources in the context of fault tolerance and elastic scalability.} (a) Fault tolerance based on number of failed nodes. (b) Elastic scalability of the EB-AI Resource Manager.}
		\label{fig:fault_tolerance_scalability}
	\end{center}
\end{figure}

Fig.~\ref{fig:fault_tolerance_scalability} shows how the training resources are used in the context of fault tolerance and elastic scalability. In order to evaluate the fault tolerance, specific resource nodes were deliberately blocked, while the impact on the overall training time was measured. As it can be seen in Fig.~\ref{fig:fault_tolerance_scalability}(a), with a hardware setup comprised of 16 nodes, the impact of failing 1 to 4 nodes is negligible on the training time. However, the impact becomes visible when 4 nodes (50\% of total available nodes) are blocked in a hardware setup of 8 total nodes. Fig.~\ref{fig:fault_tolerance_scalability}(b) shows the number of used nodes in the training process while injecting an input stream curve of 250-1200 tuples (subset data) per second. The EB-AI Resource Manager reactively allocates or deallocates nodes in order to compensate the input demand.

The performance of a DNN can be evaluated based on a series of metrics, depending on its architecture. Fig.~\ref{fig:metrics_perception} show different evaluation approaches for our object detection use-case based on direct visualization of the DNN layers' activations, Intersection over Union (IoU), as well as a performance estimator which aggregates the overall accuracy of the model into a 5-stars rating system.

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale=0.25]{metrics_perception.png}
		\caption{\textbf{Performance evaluation metrics within EB-AI.} (a) Direct visualization of the activations of each DNN layer. (b) Intersection over Union (IoU) evaluation matrix describing in percentage the amount of overlapping bounding boxes. (c) 5-starts rating aggregates overall accuracy.}
		\label{fig:metrics_perception}
	\end{center}
\end{figure}

To assess the precision of object detection, we use the IoU quality measure, which is a percentage measure reflecting the amount of overlapping between the predicted bounding box, as outputted from the AI inference engine, and the labeled bounding box. An accurate model has an IoU value close to 100\%, which represents maximum accuracy. Fig.~\ref{fig:metrics_perception}(b) illustrates the IoU matrix determined for the trained Yolo V5 model. From the obtained IoU matrix, it can be observed that the majority of the detected objects overlap in a ratio of 80-90\% with the ground truth. Featuring easy interpretability over the testing data, the user can trace back the samples where the evaluation failed or was not accurate enough, while iteratively improving the neural network until the desired performance is achieved.

The obtained AI Inference Engine contains the trained DNN model encapsulated in a deployment wrapper. In this case, it was deployed as an ADTF wrapper on Elektrobit's Automotive Data and Time Triggered Framework (ADTF). Fig.~\ref{fig:eb_ai_obj_det_perf_statistics} shows different measure performance indicators for the four considered target ECU devices. The metrics quantify the computation time in frames per second, initialization time, as well as maximum and minimum computation time, respectively. The obtained results are proportional to the computation power of each ECU, yielding low framerates for low-range grade devices, such as the RaspberryPi, as opposed to the high performance of automotive ECUs, such as the NVIDIA AGX platform. The metrics are logged in the ECU device for latter importing into the Cloud, where they optimized by reconfiguring and retraining the DNN using the proposed data driven V-Model.

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale= 0.48]{use_case_env_per_plot_eval_statistics.png}
		\caption{\textbf{Real-time performance metrics obtained on different deployment ECU devices}. The diagrams show the Frames per Second (FPS), AI Inference Engine initialization time, as well as the lowest and highest achieved framerate for four different ECUs.}
		\label{fig:eb_ai_obj_det_perf_statistics}
	\end{center}
\end{figure}

\subsection{Use Case 2: Most Probable Path Prediction}
\label{sec:mpp}

In autonomous driving and driver assistance, in order to prepare the vehicle for upcoming hazards or to warn the driver, it is important to predict in advance the route that the vehicle will follow over a future time horizon. Such algorithms, illustrated in Fig.~\ref{fig:mpp_results}, are called Most Probable Path (MPP) estimators. With an increasing level of map details, past trips of vehicles can be used to store information about the road paths that are likely to be reached within a specified distance using GPS observations. Using this information, the MPP algorithm can learn and further predict the probable road network ahead. As the vehicle travels forward, travelled road segments are left behind, while new ones are added to the MPP.

\begin{figure}
	\centering
	\begin{center}
		\includegraphics[scale=0.455]{MPP_results.png}
		\caption{\textbf{Comparison between different MPP computation methods}. a) Ground truth. b) Prediction given by a classical (non-AI) method. c) Correctly predicted path using an AI Inference Engine.}
		\label{fig:mpp_results}
	\end{center}
\end{figure}

A map is a web of paths implemented using a tree structure, where each node in the tree represents a link between two segments of the road. The root node of the tree represents the link where the vehicle is currently located. Starting from a link, the vehicle can travel to a considerably large number of possible paths. A transition from one link to a reachable successor is represented by adding a child to the proper parent node in the tree. This is important because as the vehicle travels forward, nodes that become unreachable are removed from the tree. Every time the vehicle transitions from one link to the next, at least one node becomes unreachable and will be removed from the graph.

In order to predict where the vehicle is heading in the future, the MPP method needs to calculate the likelihood associated to each possible turn. In the classical way, the weight associated to each turn, or transition, depends on many factors and considers the turning angle and the road class of the following road segment. A smaller turning angle results in a higher probability of driving straight, whereas a bigger turning angle results in a smaller probability of following that specific road segment.

The main drawback of the classical approach in computing the MPP is that in most cases these predictions are performed at a small distance (a few hundred meters) in front of the current position, since the computation time required for computing the MPP probabilities is high. Additionally, the result will always be similar, since the turning angle and road class will be constant on the same map, so there will never be any difference between different drivers or different cars.

In this use-case, we have trained and deployed an AI Inference Engine using GPS data collected with Elektrobit's autonomous test vehicle, shown in Fig.~\ref{fig:mpp_car}. We have performed $25$ trips of $40km$ each. Using the EB-AI framework, we were able to enhance the links using the pre-processing operations. As in the environment perception use-case example, the user can split the ratio of training data between train, validation and test datasets.

\begin{figure}
		\centering
		\begin{center}
			\includegraphics[scale=0.5]{EB_Car_2.jpg}
			\caption{\textbf{Test vehicle used for data acquisition and testing for the MPP AI Inference Engine.}}
			\label{fig:mpp_car}
		\end{center}
\end{figure}

The DNN at the core of the AI Inference Engine is a Recurrent Neural Network (RNN) consisting of $256$ Long-Short-Term-Memory (LSTM) units, followed by a Fully Connected layer (SoftMax activation), providing as output a list of predictions of the most probable paths. We have chosen an RNN network architecture due to its robustness in processing time dependent sequences, thus encoding the links relations in its memory cells. EB-AI was used to efficiently design and optimize the neural network. The obtained AI model wrapped in the ADTF format was deployed in a container ready to run on a NVidia Jetson AGX board mounted in the vehicle from Fig.~\ref{fig:mpp_car}.

To evaluate the performance of the MPP approach, EB-AI provides the means to measure the similarity between two paths, namely predicted and ground truth. The output of the DNN is a list of paths ordered by the probability of being the correct one. Fig.~\ref{fig:mpp_perf_rez_avg_corr_route} shows the average position of the most probable route as the trip advances. The $y$ axis in the figure represents the ground-truth reference path and the DNN predicted path, order based on their probabilities. We show the top most probable paths estimated by the neural network. Ideally, the predicted path should be the same as the reference one. In the beginning, when little information is known about the past vehicle's route, the MPP has a lower accuracy. The accuracy increases gradually as the drive progresses, reaching top match after kilometer $25$.

\begin{figure}
		\centering
		\begin{center}
			\includegraphics[scale=0.62]{use_case_mpp_avg_corr_route.png}
			\caption{\textbf{The average correct route match relative to the travelled distance.} At halfway through the $40km$ trip, the predicted route is within the top 5 matches, while in the last $10km$ the predicted route is the top match.}
			\label{fig:mpp_perf_rez_avg_corr_route}
		\end{center}
\end{figure}

An additional performance metric is the correct prediction rate of the DNN. Fig.~\ref{fig:mpp_perf_results} presents how often the MPP correctly predicted across different trips. The left most graph presents the results obtained when driving all the time on new routes, while the right most graph illustrates the results obtained when driving repetitively on the same routes.

\begin{figure}
	\centering
	\subfloat[]{\label{fig:mpp_corr_pred_route}\includegraphics[scale=0.5]{figs/use_case_mpp_corr_route.png}}
	\subfloat[]{\label{fig:mpp_corr_pred_repeat}\includegraphics[scale=0.515]{figs/use_case_mpp_repetitive_route.png}}
	\caption{\textbf{Performance of the MPP algorithm across different trips.} (a) Driving on new routes. (b) Driving repetitively on the same routes.}
	\label{fig:mpp_perf_results}
\end{figure}

redpajama_set_name: RedPajamaArXiv


Sutorbilt Legend Series are available with grease/oil lubrication and dual splash lubrication (DSL). Legend Blowers feature a cast iron casing with dynamically balanced bi-lobe impellers. Mechanical seals are available for gas applications.
Sutorbilt 4500 Series permits higher speeds, performance ratings and is rated for continuous duty in all industrial applications. 4500 Series feature ductile iron bi-lobe impellers equipped with one-piece alloy steel shafts. Mechanical gas seal are available for gas applications.
Sutorbilt 8000 Series are synonymous with LARGE flow applications. Available in 10" - 22" gear diameters. 8000 Series feature dynamically balanced impellers constructed of high-density ductile iron. Mechanical gas seals are available for gas applictions.


Please Like My Page on Facebook. https://www.facebook.com/pages/Pick-3-Mastery/746097795502105?pnref=story Please leave a comment and give the page 5 stars! I have started to work on Cheat Sheet-3. It will be better and more accurate than Cheat Sheet-2!!


As I watched Condeleeza Rice last night, that line stuck in my mind. In fact, I kept thinking about it while I was working last night, and then catching up on Twitter and my other news feeds.
During the perusal of my RSS last night, that line echoed in my head as I came across a photo of a "Code Pink" protester dressed as a female body part, and holding a sign that said "Abortion on demand". The juxtaposition of that image, and Ms. Rice's speech showed just how stark the contrast is between those who believe in this country, and those who don't.
One group of photos showed accomplishment, achievement, intelligence, generosity, and purpose.
The other photo showed "gimme, gimme, gimme".
There is no other way, in this country to get anywhere. You go as far as you allow yourself. You go as far as the effort you put into your life takes you. But, that is something that is falling on deaf ears with many in this country. We have gotten to a point where success, any kind of success, is vilified, demonized, and even, if some had their way, criminalized.
I saw another picture. It was of one of the Occupy Movement protesters, holding a sign that said "What about me?" And then, I looked at my wall, and there was a photo of my dad. Dad worked hard. Dad demanded that we work hard. Dad guided us, and filled us with the values of hard work, honesty, integrity, decency, faith in God, and faith in our abilities. Dad was a manager, a firefighter, and then Fire Chief, he was also a small business owner. Dad could burn the midnight oil like nobody else, get up the next day, and do it all again. I remember the times when I was a petulant teenage know-it-all challenging any value he held, and remember being shown, not told, how I was wrong in my self-righteous and self absorbed beliefs. I was shown the example Dad showed and lived. See, he didn't tell me, or my brothers and sister, he showed us.
Entitlement abounds. People, especially young people, not only want, but demand that things be given to them at the expense of others. And when someone dares to speak about how that isn't going to be, the speech is met with viciousness. Not disagreement, no. Viciousness. Verbal attacks calling for the destruction, death, or injury of the speaker. If that speaker just happens to be a "person of color", the attacks are even worse. It's not fringe lunatics doing this either. It's the mainstream. Actors, Actresses, "news" anchors, commentators on national networks. This isn't disagreement, this is hatred. It is "You either agree with me, or face the consequences".
We live in a society that is more than ever before, lazy, self indulgent, demanding, and amoral. We are at the precipice.
We are at the cusp of a future that can either lead us back, or take us out.
It's not just about the President we elect either. It starts, or ends, with the decision that is made in November. It is going to take more than a Presidential election, or even gubernatorial, Congress, or Senatorial. Those are all starting points. The changes, the real changes have to come from the people. We have to start pushing back against the tide of corruption, ignorance, immorality, decay, debauchery, and destruction that this society has become. We, as a people, have to pick up the standard of values, and start carrying them.
We have to be like my Dad. We have to show, not tell. Dad did things for people without any other consideration, beyond the fact that they were a person who needed something. We don't have to do big productions, we don't have to call attention to calling for a moral shift. We just have to act. When we act in the small ways, eventually, it changes the big things. We start, by teaching these things to our kids.
This is the future of the United States of America. Romney and Ryan can set the course, we must steer the ship. It's not enough to have jobs and prosperity. We have to show what this country has always been about, we have to live the values, not just talk about them. It may seem impossible, but, we must make it inevitable.
Jesus told us to "be the light of the world" and a "city on the hill". That we must do. Whatever your faith, it is what we must do. We must bring this country back, not only in the economic, and leadership sense, but as a society of values.
It can't be any other way.
The Anniversary of the Attack.
Everyone is reflecting on 9/11 this day. It would be cliche for me to write about where I was and what I was doing on that day. Since I do not like being cliche, I won't. That day did affect me profoundly, on levels I cannot even describe.
What did affect me was the way today, ten years after the most vicious attack on this country since Pearl Harbor, dawned. It was the same as it was 10 years ago, maybe a bit cooler, who knows? I went about my morning, getting ready for church, and going to the Pancake Breakfast at the fire house. My mind kept going back to that morning. I cannot explain how it affected, at least, I cannot explain completely.
As the years have gone by, I have never completely forgotten the images I saw that morning, they were too horrific, too frightening, and even, too surreal to forget. Part of my heart was in those towers on that day, it was there with the firefighters of the FDNY. As I watched the towers burn, in my mind, I could see the firefighting activity going on. I could only imagine how crowded the radio channels were, and the chaos that must have been taking place at the 9-1-1 Center, and in the "radio room" (regardless of it's size, and number of occupants, where ever the fire dispatchers are located, it is always called the "radio room") My mind was in several different places at once. I never in my life fought a fire of any type approaching that level of intensity, and I certainly do not put myself on the same level as a firefighter in a big city. That being said, we share the same bond, in many ways. I also know the fire service from the dispatch side of things. I know how hectic it can get in a given dispatch center during a "regular" incident (Large auto accident, big fire, etc) I could only imagine the stress and the strain the dispatchers were going through, and through it all, each one maintained their professionalism and communicated clearly and effectively.
So, that was one level… and then there is the other one. My mind is still haunted by those images, especially of the people jumping, and the footage of the people trapped above the fire in both towers. The images were heart-rending, and to this day, are difficult to watch. Watching video is one thing, but seeing the still photos, is something else. Even though you can't see individual expressions, the fear is palpable nonetheless. It's hard at this point, not to lapse into meaningless cliche about who those people were, their dreams, desires, what they did, who they loved. It's all been done, and I cannot do it any more justice, but, I do feel that aspect, and it makes things all the more unforgettable. All of those faceless people in those grainy photos and video of the upper floors, were someone to somebody, and they all left this world in a way none of them expected. I often find myself wondering what that day must have been like, especially for the person who looked out the window just as the aircraft approached. I cannot fathom that feeling, and I cannot fathom what it must have been like. Even worse, the people on the plane, who knew, like that flight attendant who was on the first aircraft to hit the towers, she was talking to someone from her airline's headquarters, and she knew what was going on, she knew it. I cannot comprehend what that must be like, the overpowering helplessness that must have overcome all of them. Still photos abound of the people who watched the attack, and its aftermath, unfold. They were on the street surrounding the Twin Towers, they were in buildings throughout the area, and they were in Times Square watching it happen on the "Jumbotron" TV's on some of the buildings. The photos of the people nearest the attack site are the ones that are the most unsettling. Each one shows a person, or group of people, their expressions showing a mixture of horror, and disbelief at what happened.
That's when it started, the analyst kicked in. I thought, how in the heck does an airplane crash into the World Trade Center. My first thought, before turning on the TV is to grab my Road Atlas. I quickly flip to New York City, wanting to know where JFK and LaGuardia were in relation to the World Trade Center, I found the proper page, still talking to my mom, and turned on the TV. I didn't expect to see what I saw. A huge amount of smoke was pouring from the 1st tower that had been hit. I remember saying. "That had to be a huge plane that did that mom, that's got to be 8 or 10 floors on fire, the only plane that's going to do that is an airliner." and she replied. "Well the news is saying they don't know what kind of plane it was." I hung up and sat to watch. My mind was seeing the images on the screen, and listening to Diane Sawyer, but the other part of my mind was thinking.
What kind of plane was it?
How did it hit the tower?
How fast was it going?
How many people on board?
and the most chilling of all. "It had to be deliberate". To me, at that moment, nothing else made sense. I have spent my life, literally, studying World War II, and that also lead to study, and reading about military history in general, as well as terrorism. That also led to learning about military strategy, military thought, and other things I cannot list. My analytical mind was coming to only one conclusion. Terrorists did it. At that moment, it was the only thing that made sense to me. Airplanes just don't take off from an airport, and crash into skyscrapers. The term "accident" was dismissed completely from my mind. I knew an attempt was made in 1993 to destroy the WTC by Islamic Terrorists. Somehow, I knew I was watching their second attempt at it. As if to underscore that line of thought, the second aircraft hit the other tower. Then I knew, beyond the shadow of a doubt it was deliberate. Immediately, my mind was in overdrive. A deep sense of foreboding told me it wasn't over, that there would be more. My mind was racing, listing potential targets, and dismissing them. I then began to look outside for the signs that a plane was heading for the Sears Tower. By now, one had hit the Pentagon, and the news was reporting that another aircraft was missing, and presumed to be heading for Washington.
I couldn't contain myself anymore. I was on the computer, trying to do my own amateur analysis of who the culprits were, and before his name was even spoken on the news, I knew it was Osama Bin Laden. I pulled an old copy of the Naval Institute's magazine, called "Proceedings" from my bookshelf. In it, was an analysis piece about Osama Bin Laden written in 1999 I think. I could think of no other person, and no other group other than Al Qaeda. I had the radio, computer, and television going all at once, I was on the phone with my friend Peggy from Ohio, talking about the situation in New York. Just then, I heard the high pitched roar of what could only be fighter planes flying overhead. I leapt to my front window, and grabbed the binoculars I always kept nearby. I caught them out of the corner of my eye, and turned the binoculars to the movement, after a momentary wobble, I settled the binoculars on the aircraft. 4 F16's were clearly visible, flying in two pairs, and what really struck me was the fact that they were armed. "Sidewinder" missles were clearly visible on the wing tips. As fast they appeared, they were gone, rocketing northeast. I continued my conversation with Peggy, as we both watched the coverage on ABC at our respective homes.
I will never forget how I felt that day, and I will never forget how this has affected me. To watch the documentaries, as I did yesterday, it is almost haunting. What was scary, or, perhaps, just weird, or whatever, is how some of the documentaries echoed some of my initial thoughts on the day's events, some of the people involved, in both Public Safety, and the Federal Government were thinking the same things I was thinking in the initial stages of the day's events.
9/11 haunts me, in ways that I can't even describe. On one level, it's the memories of what I saw, and then on other, deeper levels, it's an almost frightening understanding of the machinations that brought us to that point.
Like others before them, those who wish to inflict a given political, or belief system on a society, through terror, are not "madmen" or "out of there minds" they are not "twisted" or irrational. They are rational, by their own standards, and, like many before them, people like Hitler, Stalin, Mao, just to name a few, the aforementioned labels do not fit, and are not even appropriate.
A "madman" may be frightening, but a madman is not rational, he is not calculating, he doesn't think systematically, he acts on impulse, and destroys things without rhyme, reason, or a greater, if you will, purpose. Hitler, Stalin, and the Islamists were not, and are not madmen either. They are cold, calculating, political creatures, who would willingly waste human life in pursuit of their political goals. That is what makes them more frightening than a madman. They believe, and because they believe, they will act. And they did just that. That is where the understanding has to start, and the understanding is necessary so we can protect ourselves in the future, and strike them down if necessary.


text:
//  Copyright 2021 The KeepTry Open Source Project
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//

package string.parentheses;

import java.util.HashSet;
import java.util.Set;
import java.util.Stack;

public class Leetcode1249MinimumRemovetoMakeValidParentheses {
  /*
      Leetcode 1249. Minimum Remove to Make Valid Parentheses

      Given a string s of '(' , ')' and lowercase English characters.
      Your task is to remove the minimum number of parentheses  '(' or ')', in any positions
      so that the resulting parentheses string is valid and return any valid string.

      Formally, a parentheses string is valid if and only if:
      It is the empty string, contains only lowercase characters, or
      It can be written as AB (A concatenated with B), where A and B are valid strings, or
      It can be written as (A), where A is a valid string.

      Input: s = "lee(t(c)o)de)"
      Output: "lee(t(c)o)de"
      Explanation: "lee(t(co)de)" , "lee(t(c)ode)" would also be accepted.

      Input: s = "a)b(c)d"
      Output: "ab(c)d"

      Input: s = "))(("
      Output: ""
      Explanation: An empty string is also valid.

      Input: s = "(a(b(c)d)"
      Output: "a(b(c)d)"

      Constraints:
      1 <= s.length <= 105
      s[i] is either'(' , ')', or lowercase English letter.
  */
  /*
  Observe:
    - before meeting (,  any )  is invalid, need remove it
    - any ) left without paired ( is invalid, need remove it
    use Stack to keep invalid parentheses index, need to know its location in string

  minimum: means only delete invalid ones
  O(N) Time and space
  */
  public String minRemoveToMakeValid(String str) {
    Stack<Integer> stack = new Stack();
    for (int i = 0; i < str.length(); i++) {
      if (str.charAt(i) == ')') {
        if (!stack.isEmpty() && str.charAt(stack.peek()) == '(') stack.pop();
        else stack.push(i);
      } else if (str.charAt(i) == '(') stack.push(i);
    }
    StringBuilder r = new StringBuilder();
    for (int i = str.length() - 1; i >= 0; i--) {
      if (!stack.isEmpty() && stack.peek() == i) stack.pop();
      else r.append(str.charAt(i));
    }
    return r.reverse().toString();
  }
}

redpajama_set_name: RedPajamaGithub