% $Id: ecsl.tex,v 1.10 2005/11/02 13:44:16 kitty Exp $

\section{Applying MIC to develop embedded automotive applications}
\label{ecsl}

Embedded automotive systems are becoming notoriously difficult to design
and develop.  Over the past years there has been an explosion in the scale
and complexity of these systems, owing to a push towards drive-by-wire
technologies, increasing feature levels, and increasing capabilities in the
embedded computing platforms.  In order to address this level of
complexity, the automotive industry has in general embraced the model-based
approach for embedded systems development. However the approach is confined
to only the functional aspects of the system design, and restricted to a
limited suite of tools, most notably
% Kitty, could you please find the Latex command for the
% copyright/trademark symbol that shows up here - Andy
% Fixed. - kitty
the Mathworks family of Matlab\textsuperscript{\textregistered},
Simulink\textsuperscript{\textregistered} (SL),
Stateflow\textsuperscript{\textregistered} (SF) tools.  Undeniably,
Simulink and Stateflow are very powerful, graphical system design tools for
modeling and simulating continuous and discrete event-based behavior of a
dynamic system.  However, these tools by no means cover the entire spectrum
of embedded systems development.  There are several other complex
activities such as requirement specification, verification, mapping on to a
distributed platform, scheduling, performance analysis, and synthesis in
the embedded systems development process.

While there are tools which individually support one or more of these other
developmental activities, the integration among these tools and the
Mathworks family of tools is often lacking, which makes it extremely
difficult to maintain a consistent view of the system as the design
progresses through the development process, and also requires significant
manual effort in creating different representations of the same system.  To
address the deficiencies in the development process for distributed
automotive embedded systems, we built the Embedded Control Systems Language
(ECSL) that provides the ability to import existing SL/SF models into a GME
environment, and supports: (1) The annotation of structural design,
SW-component design, and behavior implementation to supply information
needed by a code generator, (2) Creation of HW-topology design models,
Electronic Control Unit (ECU)-design models, and firmware implementation
design models, and (3) Creation of deployment models that capture component
and communication mapping.

\subsection{Embedded System Development using ECSL}
% Folks, we need to shorten the description here - andy
Figure~\ref{fig:ecsl-process} below depicts the conceptual view of
activities in an automotive embedded systems development process, as
supported by the ECSL tools.  Each rounded block denotes a particular
activity and arrows indicate the workflow between different activities.
Activities can roughly be grouped in three blocks: {\em Hardware Design},
{\em Software Design}, and {\em Mapping}. {\em Requirements Engineering} is
not within the scope of this tool-suite, although it is the basis for most
of the modeling and development activities.

\begin{figure}[htbp]
  \centering
  \includegraphics[width=\columnwidth,keepaspectratio]{ecsl-process}
  \caption{ECSL Process}
  \label{fig:ecsl-process}
\end{figure}

\noindent{\bf Software Design} deals with: a) Structural design, which
refers to the hierarchical decomposition of the embedded system into
subsystems and sub-subsystems, from a functional viewpoint, b) Component
design, which is another form of decomposition not independent of the
functional decomposition, deals with more of the classical embedded
software concerns such as real-time requirements, real-time tasks,
periodicity, deadline, and scheduling, and c) Functional/behavioral design,
which refers to the elaboration of the leaf elements of the hierarchical
structural design in terms of a synthesizable realization.

\noindent{\bf Hardware Design} includes the specification of ECU-s in a
network and their connections with buses, defining an architectural
topology of the distributed embedded platform. Refinements of this activity
include design of individual ECU-s, selecting the processors, determining
the memory and I/O requirements.

\noindent{\bf Mapping} includes activities involving both software and
hardware objects, like decisions regarding the deployment of certain
complete or partial functions to hardware nodes which are part of the
network, and the assignment of signals to bus messages.

\noindent{\bf Code Generation/Implementation} involves creation of
low-level coding artifacts, which include RTOS configuration, firmware
configuration code, and behavioral implementation of the components.

Figure~\ref{fig:ecsl-process} captures an abstraction of the design
process, which is made concrete by a number of supporting tools, which
include:
\noindent{\bf GME/ECSL.} This is the Generic Modeling Environment tailored
to support the ECSL modeling language.
\noindent{\bf ECSL/CG.} A specialized code generator that produces various
production artifacts (e.g. source code, configuration files, etc) from ECSL
models.
\noindent{\bf ML2ECSL.} Import translators that allow importing SL and SF
models into the ECSL modeling environment.
\noindent{\bf SL/SF.} These are the Simulink and Stateflow tools.

\subsection{Embedded Control Systems Language}

ECSL is a graphical modeling language built using GME.  It contains
modeling concepts for specification of the design activities listed
above. The language has been designed as a composition of a suite of
sub-languages as shown below:

\noindent {\bf Functional Modeling.} The Simulink and Stateflow
sub-languages of ECSL were designed to mirror the capabilities found in SL
and SF, such that all models could be imported into the GME environment
configured to support ECSL.  Simulink follows a dataflow-diagram like
visual notation, while Stateflow supports Statechart-like hierarchical
finite state machines.

\noindent {\bf Component Modeling.} This sub-language allows software
modeling in two stages: (1) integrating models that were imported from
SL/SF, and (2) allowing their componentization.  A component is defined as
a portion of the software model, which is deployed as a unit.  The
componentization is specified using the GME containment and reference
capabilities:  Components are GME models that contain references to
elements of the functional model (imported from SL).  Components consist of
ports which allow the specification of inter-component communication, as
well as interfaces to physical devices including sensors and actuators.
Attributes of ports capture the required communication properties like data
type, scaling, bit width etc.  The intra-component dataflow exists within
the functional models and it is imported from SL/SF.  The inter-component
dataflow is introduced by the designer after creating components from the
imported SL/SF models.

\noindent {\bf Hardware Topology Modeling.} The hardware modeling
sub-language of ECSL allows the designer to specify the hardware topology,
including the processors and communication links between the
processors. ECU models represent specific processors in the system.  An ECU
model has two kinds of ports for representing the I/O channels and the bus
connections. I/O channel ports come in two variants: sensor ports and
actuator ports.  The specifics of the ECU firmware, and characterization
with respect to memory sizes, CPU speed, etc. is captured with attributes.
Bus models represent communication pathways used to connect ECUs.  Buses
are expressed as GME atoms and their attributes specify various properties
of the physical communication system (e.g. bit rates).

\noindent {\bf Deployment (Mapping) Modeling.} This modeling sub-language
captures how software components are deployed on the hardware.  The ECU
model has a ``deployment aspect'' that allows the designer to capture SW
component to ECU mapping using GME's reference concept.  Note that
deployment models are separate from software models, thus allowing the
reuse of software models in different HW architectures.  Furthermore,
component ports are connected to ECU ports (sensor, actuators, and bus
connections) to indicate how the component software interfaces map to
actual sensors, actuators and buses.

\subsection{Generating code and other artifacts}

The ECSL/CG tool is a code generator that produces code artifacts necessary
for system implementation as shown on Figure~\ref{fig:ecsl-cg}.

\begin{figure}[htbp]
  \centering
  \includegraphics[width=\columnwidth]{ecsl-cg}
  \caption{ECSL Code Generation}
  \label{fig:ecsl-cg}
\end{figure}

The following types of files are generated: (1) {\bf OSEK Implementation
  Language (OIL) File} - For each ECU-node in the network an OIL file is
generated, that includes a listing of all used OSEK~\cite{OSEK} objects and
their relations, (2) {\bf OSEK Tasks and Code} - All tasks are implemented
in one or more C files, (3) {\bf Application Behavior Code} - A separate
function is generated for each application component that implements the
behavior of the component.  This function is called out from within a task
frame, (4) {\bf Glue Code} - The glue code comprises one or more C
code/header files that resolve the calls to the Controller Area Network
(CAN) driver or the firmware in order to provide access to CAN signals or
HW I/O signals.

% For illustrative purposes, Figures~\ref{fig:ecsl-sl}
% and~\ref{fig:ecsl-sf}, below show the (GME-style) meta-models for the
% functional portion of ECSL which are used to hold models imported from
% Simulink and Stateflow.

% Folks, if we are not discussing what is in the metamodel we should
% try to comment these figures away and only focus on the features,
% and an example - andy

% \begin{figure}[htbp]
%   \centering
%   \includegraphics[width=\columnwidth]{ecsl-sl}
%   % Need to add this due to large white space - andy
%   \caption{ECSL Simulink Import}
%   \label{fig:ecsl-sl}
% \end{figure}


% \begin{figure}[htbp]
%   \centering
%   \includegraphics[width=\columnwidth]{ecsl-sf}
%   % Need to add this due to large white space - andy
%   \caption{ECSL Stateflow Import}
%   \label{fig:ecsl-sf}
% \end{figure}

% Sandeep: we can skip this figure
% Conceptually, the deployment models
% implement the mapping as shown on Figure~\ref{fig:ecsl-mapping}.
%
%\begin{figure}[htbp]
%  \centering
%  \includegraphics[width=\columnwidth]{ecsl-mapping}
%  \caption{ECSL Mapping}
%  \label{fig:ecsl-mapping}
% \end{figure}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "IEEE06"
%%% End:
