C O V E R S T O R Y AUTOMOTIV E S OF T WARE

SOFTWARE ARCHITECTURE
WITHOUT AUTOSAR
Autosar is not suited for every embedded software architecture application. Due to its wide-ranging diversity,
Autosar places high demands on the resources provided by the microcontroller and therefore represents a
considerable training effort. There are smaller systems, not only in the automobile but also in the industrial
environment, for which an architecture of this type is simply overkill and too complex. These cases call for a
simple, modular, and universal architecture. This is for instance sufficient for an “electric vehicle (EV) charging
cable”, which is a showcase example for an interface product between industry and automobile applications.

AUTHORS

DR. GALIB KRDZALIC

is Head of the Software Development
and Embedded Systems Department
at Gigatronik in Stuttgart (Germany).

ALEXANDER DRISS
is a Software Developer at Gigatronik
in Stuttgart (Germany).

FIGURE © adventtr/iStockphoto.com

ARCHITECTURE DESCRIPTION design process and therefore the result-

In today’s embedded systems, software
increasingly gains in importance due to
increasingly powerful micro controllers
(μC). The focus for development is no
longer on hardware design; instead, the
two disciplines are increasingly in equi-
librium. By now, software is developed
using defined processes that have been
established over time based on the
insight that reliable software develop-
ment processes improve the quality of
software and therefore the system as a
whole. At times, the software develop-
ment process encompasses the software
ing software architecture.
The software (SW) architecture
describes the entire SW system at a
graphic abstraction level using UML (Uni-
fied Modeling Language). This places the
focus on the package level view from
among the large variety of different UML
descriptions. The package view is based
on components and modules which are
an abstract rendition of the various layers
pertaining to the hardware. ➊ shows a
package view as it can be used for embed-
ded systems. The following proposes the
thesis that each software of an embedded
system can be described with this pack-

28 www.autotechreview.com
age view representation.
MODULE STABILITY
As can be seen in ①, the diagram repre-
sents the module overview in its abstract
from. The abstraction increases from bot-
tom to top in reference to the hardware.
The more abstract a module is, the more
rigid it is to changes in its functionality,
but it continues to be open to modifica-
tions [1]. This can easily be recognised in
that the effort for changes grows as the
number of inputs (includes) for a module
increases ①, Eq 1:
Ce
EQ. 1 I=
Ca + Ce
I= Instability [0;1], this means that
“0” is equivalent to stable, and “1” instable
Ce = output dependencies
Ca = input dependencies
This formula can be used to deter-
mine the stability of individual modules.
At the same time, the stability calcula-
tion can be used to represent the rela-
tionship to the module abstraction in the
entire system. Stated more clearly: The
deeper a module is embedded in the soft-
ware architecture, the less complex it is,
①. When considering the drivers in ①,
they strictly have the task to store exter-
nal signals (on sensors) in a ring buffer
or to output signals (to actuators).
DRIVERS
Drivers serve as interfaces between the
actual hardware environment and the
abstract software. This layer is needed for
all embedded software systems; otherwise
these would not able to respond to their
environment in software or hardware real-
time. The response to soft events is
accomplished with polling. This either
involves periodic monitoring of the availa-
ble signals, or immediately storing signals
in a memory buffer via interrupts (hard)
when they occur, and processing these
signals on the next processing cycle.
SIGNAL WRAPPERS
The signal wrapper, ❷, is the next higher
autotechreview A p r il 2 014 Vo lu m e 3 | Is su e 4
level in ① (package view diagram). This
layer has the task of abstracting the
received information and to make it avail-
able to the higher ranking layers. The sig-
nal wrapper module facilitates the simple
exchange of the μC while the hardware
stays the same, for this would require
adapting the driver layer. This adjustment
can be quickly and conveniently imple-
mented while maintaining the interfaces;
the reason for this is the very simple pro-
gramming of the drivers.
When the μC and the hardware
changes, the system can still be ported
very quickly by adapting the drivers and
the signal wrapper when the system
requirements continue to stay the same.
These two layers render the software
highly flexible in response to hardware
changes and allow the system to be
adapted to new platforms relatively easily
with minor changes. As is the case with
all other components from other layers,
the signal wrapper module can be consid-
ered to be a sub-system which in turn is
comprised of several individual modules
which are then responsible for the respec-
tive driver, ②.
FUNCTIONAL AND
NON-FUNCTIONAL MODULES
The functional and non-functional sub-
systems, which consist of various mod-
ules, are embedded above the signal
wrapper level and below the state
machine level. Due to their existence in
the system it is critical that a large portion
of the system requirements is already
known before the actual software design
is developed. This sub-system is different
for each embedded system because it
describes the actual system task.
Despite the different tasks performed
by embedded systems, this sub-system is
found with other but also the same mod-
ules in every software architecture for
such a system. The sub-system of non-
functional requirements does not neces-
sarily have to be present since these
requirements describe properties of the
system that not only flow into the non-
functional sub-system but also into the
runtime module.
Non-functional requirements for
instance describe the responsiveness of a
system, the resource assignments, or the
➊ Package view for embedded systems
various processes needed by a system to
perform its tasks.
STATE MACHINE
The modules of the described sub-systems
are used by the next higher layer, the state
machine. The state machine, whose func-
tionality can be regarded as a scheduler,
follows a fixed sequence of tasks [2]. The
tasks can be processed in a time- or event-
controlled manner. The structure of this
sub-system forms a solid foundation for
the reuse of systems that need to fulfill
the same program sequence based on dif-
ferent requirements. The processing of
states can for instance be based on stand-
ards that define a certain sequence for a
system, allowing this module to be
quickly and conveniently adapted for
other platforms.
When hardware and/or requirements
change for an already existing embedded
system, essentially only the lower ranking
layers need to be adjusted if the system
sequence remains the same.
RUNTIME (OS) AND MAIN
The runtime (OS) layer is a component of
each embedded system in its various ver-
sions. It is responsible for scheduling
tasks and the corresponding resources.
The top and last layer is the main
layer. Its only role is to call the runtime
(OS) layer repeatedly and to create a cycli-
cal sequence of the system.
Helper modules – frequently needed
but not always present – do not represent
a significant development effort, but are
frequently not implemented without
defects. A counter is an example for a
helper module. A counter can be realised
29
C O V E R S T O R Y AUTOMOTIV E S OF T WARE
➋ Signal wrapper module
in a variety of ways – and therein lies the
problem. For this reason, the wide range
of implementation options represents the
weakness as it pertains to the software
failure modes. Yet another aspect and also
a reason for introducing and maintaining
helper modules can be the readability of
program codes.
When projects and the whole company
use only one type of counter develop-
ment, every developer immediately knows
how the counter works in detail. Moreo-
ver, the counter has already been tested
since it should otherwise not be released
for reuse. In summary, the software has
the following benefits:
:: improved readability
:: shorter training
:: easier to understand
:: possibly a better software structure,
since the helper modules always need
to be used in the same manner.
Moreover, helper modules can be created
for the following issues:
:: data logging
:: diagnostics
:: boot loaders
:: signal filters
:: queues
:: RAM/ROM test (patterns)
:: stack overflow
:: ALU test
:: miscellaneous processing algorithms.
CREATING FLEXIBLE
SOFTWARE ARCHITECTURE
All embedded systems can be based on
the layers described above. The package
view diagram shown above therefore rep-
resents a general software architecture
approach for embedded systems. When a
system is structured as described above,
or when the user wishes to reuse compo-
nents from one system in another system,
this can be accomplished with relatively
little effort based on the same interfaces.
30
➌ Inserting flexible layers and modules
The individual components and modules
of a sub-system can be conveniently
replaced by others using the same
approach, without this destroying the
entire system as long as the interfaces
remain the same.
When the functionality of a sub-system
or module needs to be changed, this
becomes increasingly challenging for the
developer the higher the sub-system mod-
ule ranks in the diagram. Due to their
dependencies (inputs), sub-systems or
modules of higher ranking abstraction lay-
ers are fixed in terms of changes since
changes in higher ranking layers can trig-
ger changes in lower ranking layers.
Accordingly, this presents the option to
insert “flexible” modules/layers in or
between theses layers, wherein these
serve as communication interfaces
between the changing and the unchang-
ing sub-system/module, ❸.
This approach allows the developer to
reuse already existing modules that have
already been verified. The module does
not need to be changed but is instead
amended by a flexible module. This
method of expansion allows the reuse of
certified modules, for instance based on
the “safety integrity level”, and to expand
these by flexible modules. A recertifica-
tion is not necessary. Only the newly
amended modules may need to be certi-
fied if this is relevant. This allows even
safety-critical embedded systems to be
newly developed quickly and with rela-
tively little effort.
APPLICATION
In the embedded software field,
Gigatronik Stuttgart GmbH uses the
described architecture with its simple and
universal structures in the e-mobility seg-
ment. The current architecture for EV
charging cables is entirely based in the
architecture template, ①, described here.
This facilitates fast and convenient expan-
sion options pertaining to standards still
in the draft status but also keeps the
option at hand to quickly replace the
micro-controller by adjusting the “signal
wrapper” and “driver” layers. The various
charging statuses from the IEC 61851
standard have been implemented in hier-
archical “State Machines” to facilitate a
flexible program sequence in response to
retroactive changes.
Accordingly, in terms of its flexibility
the architecture template is very similar
to the Autosar/Jasper architecture in
which components can also be conveni-
ently reused and replaced by employing
unchanging interfaces in various control
devices.
CONCLUSION
The described model can be quickly and
conveniently used as a template for
embedded software architectures. But this
does exclude the possibility for system
requirements that specify direct communi-
cation between sub-systems/modules.
Conversely, the implication for design and
architecture is that communication
between sub-systems/modules that goes
beyond the layers is indispensable – for
instance involving direct communication
between the signal wrapper and the state
machine. Layers are typically skipped
when system performance and response
speed is a critical consideration.
REFERENCES
[1] Martin, R.C.: Design Principles and Design
Patterns, http://www.objectmentor.com/resources/
articles/Principles_and_Patterns.pdf, 2000
[2] Siemers, C.: Handbuch Embedded Systems
Engineering. TU Clausthal, FH Nordhausen Private
FH Göttingen
Read this article on
www.autotechreview.com
www.autotechreview.com