Software Architectures and Embedded Systems

Introduction Software architecture has emerged as an area of intense research over the
past decade . A number of approaches have been proposed to deal with architectural
description and analysis , architectural styles [8], domain-specific and application
family architectures , architecturebased dynamic system adaptation , and so forth. By
and large, however, these approaches share assumptions that make them suited
specifically to the domain of traditional, desktop-based, possibly distributed
development platforms. Those (comparatively few) architecture-based solutions that
have focused on software systems for embedded devices (e.g., have had to face some
of the same challenges (e.g., applying solutions across an application family), but also
appear to have had some different priorities (e.g., ensuring efficient, architecture-
compliant system implementations).

Architectural Modeling
A large number of special-purpose architecture description languages (ADLs) have been
developed to represent different aspects of software architectures. More recently, the
Unified Modeling Language (UML) has gained widespread acceptance for a similar
purpose. Table 1 shows an overview of several ADLs and their primary foci. Only two of
these notations are specifically intended for the embedded systems domain:

1. MetaH models architectures in the guidance, navigation, and control (GN&C) domain.
MetaH tries to ensure the schedulability, reliability, and safety of the modeled software
system. It also considers the availability and properties of hardware resources.

2. Weaves supports specification of data-flow architectures. In particular, Weaves is

specialized to support real-time processing of large volumes of data emitted by weather
satel

Two other notations also deal with issues that are relevant to the embedded systems
domain: UniCon supports modeling of runtime (though not necessarily real-time)

Page 1 sur 11
scheduling, while ROOM targets real-time computation with a combination of message
sequence charts and state charts. The more recent Avionics ADL tries to marry several
of these ideas into a single language.

Despite the above examples, many questions remain unanswered. It is unclear whether
modeling the architectures of embedded systems is inherently incompatible with semi-
formal notations such as UML. The prevailing characteristics of the embedded systems
domain would suggest that rigor and formality are a non-negotiable requirement. On the
other hand, counter-examples exist. For instance, the software architecture team
working on JPL’s Mission Data Systems (MDS) architectural framework had initially
selected UML for representing MDS architectures; the team has recently replaced UML
with an XML-based ADL , but one that still has only semiformally defined semantics.

Simple architectures
Systems that have few tasks to do and lots of time can manage with a simple
architecture as described in . The simplest one is the round robin architecture depicted
in listing 1. It has an infinite loop where each device is polled in turn and acted upon the
result. After all the devices are checked through, the loop starts again from the first
device. This works when the loop is executed very quickly so that the user does not mind
the delay of for example when pressing a button and the screen updating as a
consequence. If some devices have a higher priority, they can be checked multiple times
in the loop.

The advantage of round robin is its simplicity but it scales up poorly and has
performance constraints.

Listing 1. Round robin, adapted from

Page 2 sur 11
The round robin architecture can be complemented with interrupts, so that an interrupt
service routine can handle urgent tasks when they occur. The interrupt service routine
can also be implemented so that it does only the most essential bits of the urgent task
and the main loop does the rest when the turn of the urgent task arrives. This approach
reduces the response time of urgent tasks. Shared data problems must be taken care of,
since an interrupt may occur while some other function is handling shared data.

In function queue scheduling architecture, after the interrupt service routine has
executed the most essential tasks, it puts a function pointer into a queue of tasks for
later processing. The main loop then goes through the queue if it is not empty. The
queue can be sorted by priority for example. This way immediate response can be given
promptly to all and the rest of the task is processed later on in a desired order. If the
queue is sorted by priority, starvation of low priority tasks may occur if high priority tasks
are inserted always before a low priority task has had a chance to execute.

Developers may end up with anti-patterns when trying to get the most out of the
hardware [5]. Such bad practices are for example the use of global variables to exchange
data between functions (might lead to race conditions) and using platform specific API
calls (code is not portable). The use of an advanced architecture helps in this regard.

ADVANCED ARCHITECTURES
Monolithic and platform-dependent software is hard to port, upgrade and reuse.
Component technology brings many advantages . It can be reported that component
based development has been a success in many application domains, such as desktop
and distributed applications. A component could be classified as a reusable,
independently developed self contained part used as a building block of a system.
Component implementation is separated from component interface. Only the interface
is visible to the rest of the system - this is called information hiding or encapsulation.

Large embedded systems are complex and thus interoperability is more important than
a small performance gain. The applied architecture is similar to the ones used in general
applications, such as with desktop applications. Large embedded systems are usually
only soft real time systems, but a reduced component model is usable with a real time
operating system.

Programmers may be unwilling to use any software architecture because of their

overhead. Some measurements report that the FASAlight architecture causes execution
performance penalty of less than 14% compared to a native implementation without a
modern architecture. With large amount of function blocks (50-100), FASAlight uses 10%
more RAM, which in case of 100 blocks is just 160 bytes total. There is also a small
initialization time when starting the program.

Page 3 sur 11
Some architectures are useful in general purpose software (such as FASA) and some are
for specialized use (for example AUTOSAR is for automotive use). A comparison based
on the quality features of each architecture is shown in table 2.

It seems that there is no clearly defined boundary to when a simple loop architecture is
sufficient and when an advanced architecture is required. For example there is a
particular case study with AUTOSAR which is an application that controls five interior
lights of a car. Even that system is complex enough to benefit from an advanced
architecture.

A. Koala
The Koala Component Model was developed for consumer electronics . The researchers
found out that the size of embedded software doubles every year, the diversity of
products increases and development time has to be decreased. They saw that the
solution is to use and reuse components within an explicit software architecture.
Reusing software saves development time and that is the key element of the Koala
architecture. Encapsulating code as libraries is not sufficient with low level code reuse.
Architectural description language is used to visualize the selected components and
structure.

In the Koala model a component is a unit of design. A product is called a configuration

and it consists of components. The component developers do not assume any
configuration and configuration designers do not modify the internals of any
component. Components are developed by various developers that can store the
components into a web-based repository. Multiple components can be combined to
form a compound component. A compound component acts just like a normal
component and it simplifies large programs.

Table 2 comparison of quality features in the discussed architectures

A component communicates through an interface, which is a small set of functions

defined in C syntax. A component is defined with component description language,
where its provided interfaces and the interfaces it requires to function are listed. These
two are illustrated in listing 2 code example that is part of figure 1. Components’

Page 4 sur 11
requirements must be connected to a component that provides that service, unless the
requirement is marked optional. One component can provide service to multiple
components.

Listing 2. Interface and component definitions

Fig. 1. Koala’s graphical notation,

Modules combine the interfaces of multiple components. It can be used for example to
call the initialization interfaces of multiple components, or to combine multiple
components to provide such an interface that any of the components do not provide on
their own.

Figure 1 represents Koala’s graphical notation and the general idea is applicable also to
other architectures. The CTvPlatform is a compound component that contains

Page 5 sur 11
CFrontEnd, CTunerDriver and CHipDriver components with instance names cfre, ctun
and chip respectively. Interfaces are marked with arrows and the direction of the arrow
tells whether the component provides service through that interface or requires it in
order to function: the CTvPlatform provides IProgram and IInit interfaces and requires an
II2c interface. For example the function of the CTunerDriver is to control a television
tuner hardware via a serial I2C bus to tune in on a specific channel supplied by a front-
end component through the ITuner interface. Note how the required II2c interface can
be used by more than one component, but the provided IInit interface must be split
using a module m

B. AUTOSAR
AUTOSAR (AUTomotive Open System ARchitecture) is an open standard for automotive
software architecture . The key points of AUTOSAR are cost-efficiency, quality,
reusability and managing complexity. Traditional software developed for automotives
electronic control units is hardly reusable and the software is getting increasingly
complex. It is possible to convert traditional software into AUTOSAR architecture by
separating the existing software into AUTOSAR components and rearranging them
accordingly.

The AUTOSAR architecture consists of application software components, the run time
environment and basic software modules. The run time environment separates the
application software components from the infrastructure that is the basic software and
physical network while improving reusability. Application software components are run
in an electronic control unit (an embedded computer). The application software
components consist of runnables that are grouped into tasks for the operating system

Page 6 sur 11
Fig. 2. Overview of the AUTOSAR architecture

The underlying basic software modules have an operating system and communication
features that are clearly defined to provide compatibility between different vendors. The
interfaces that the components use are standardized and XML (Extensible Markup
Language) is used as the data format.

Figure 2 depicts the layers of the AUTOSAR architecture. Application software

components (SWCs) communicate only via the run time environment - whether they
communicate with each other or with the operating system, IO drivers, etc. in the basic
software. If the application software components are running in different electronic
control units, the system routes the calls accordingly as in the case of SWC1 and SWC2.

The AUTOSAR architecture supports multi-core systems, too. With multi-core

computing, one electronic control unit can run multiple applications and applications
with higher system requirements are possible, for example vision-based advanced driver
assistant systems that include video processing and image recognition. To run multiple
applications on one device, embedded virtualization technology can be used. The
device is then split into smaller virtual machines that can run different operating
systems and software. The hypervisor can run either on top of or without an operating
system, where the former can include significant overhead.

C. COMDES-II

Page 7 sur 11
The COMDES-II (COMponent-based design of software for Distributed Embedded
Systems - version II) is also a component-based architecture that is designed for
distributed embedded systems which need hard real-time support . It also includes
analysis techniques, advanced algorithms and data structures, automatic code
generation and compilation techniques.

An application consists of actors that communicate using labeled messages. An actor

has a task and multiple communication and physical drivers. The task contains multiple
function blocks that contain the actual code and are reusable. Actors contain the non-
functional information.

Actors are activated when a periodic or an aperiodic event is triggered. First input is
read, then it is channelled to the task within the actor and finally output is written. No
new input is read during the task execution. The task will be executed when the
operating system schedules it to run. The task can be preempted during execution as
long as it can finish before its deadline.

Function blocks that implement the concrete computation or algorithms have four
different types. Basic type have inputs, outputs, parameters and internal variables.
Composite function blocks include multiple basic or composite function blocks and are
used to achieve complex features. While basic and composite function blocks model
continuous behaviour, state machine function blocks preserve history data and thus can
model sequential behaviour. Modal function blocks are jointly used with state machine
function blocks, since modal function blocks act upon the state of a state machine
function block. One state machine function block can control multiple modal function
blocks.

The hierarchical nature of COMDES-II is shown in figure 3. On the top of the hierarchy is
the environment consisting of data lines connected to the application. Circles denote
input interfaces and squares denote output interfaces. The labeled messages the actors
use to communicate are marked as msg 1- 3. In the middle of the hierarchy is the actor.
The actor of the example has three communication drivers (white triangles) and one
physical driver (black triangle). The information from the drivers is transmitted to the
task using local signals (im1 v etc.). At the bottom of the hierarchy is the task and its
function block instances. In this example, the function blocks are either basic or
composite function blocks since state machine and modal function blocks need to be
connected to each other using two signal lanes - one for the state update message and
one for the new state.

Page 8 sur 11
Fig. 3. Hierarchical architecture model of a COMDES-II system

D. FASA and FASAlight

FASA (Future Automation Systems Architecture) and FASAlight, a version for low-end
embedded devices, are proposed here. FASA supports multi-core and distributed
systems. Applications are built as function blocks that are scheduled and monitored by
a runtime framework layer. Below the runtime framework layer is a platform abstraction
layer that can be accessed from the runtime framework and function blocks. The
platform abstraction layer communicates with the operating system. These layers are
illustrated in figure 4. Function blocks contain the application code and have an
interface called ports. Input ports and output ports are connected via a channel. A group
of blocks is called a component. Components can be executed in parallel, so CPU
bound function blocks should be organized into different components if the CPU has
multiple cores. The runtime framework consists of components such as a scheduling
component that is also interchangeable. The reference implementation uses non-
preemptive static cyclic scheduling (a fixed sequence), but other approaches are
possible.

Page 9 sur 11
The FASAlight version is designed for devices that have as little as several kilobytes of
RAM. Function blocks have only two methods: initialization and execution. Channels are
pointers to a shared memory area. The platform abstraction layer has been
implemented on Linux and Freescale MQX operating systems. Configuration is done
using hard-coded initialization code.

The normal FASA has been implemented on Linux for x86 and ARM processors with
multi-core support. Configuration is done using XML files, which was a too resource
intensive approach for the FASAlight version. The FASA reference implementation has
20989 lines of code and the FASAlight has only 2402 lines.

The components and function blocks are portable if they do not use platform specific
functionality, but only the platform abstraction layer. They are also interchangeable
between FASA and FASAlight. The platform abstraction layer can be ported to different
operating systems and processors with little effort. The programming language needs to
have a compiler in the target system.

Both FASA and FASAlight have all the most important quality features plus the ones
suitable for real-time systems (timeliness, predictability and efficiency).

A few software architectures for embedded systems were presented abover. The kind of
software architecture that should be used when developing for an embedded device
depends on the function of the apparatus, the performance of the embedded computer,
special requirements etc. Very small programs that have not much to do and plenty of
time can manage with only a simple loop architecture. If the program is not an extremely

Page 10 sur 11
small one, a more advanced component based architecture should be used. Such
architectures help manage the complexity of the program and allow the reuse of code in
later projects or ports to different platforms.

Page 11 sur 11