Introduction to Symbian Operating System

Introduction

Symbian OS was designed from its inception with smartphones as the target
platform. It is not a generic operating system shoehorned into a smartphone nor is it
an adaptation of a larger operating system for a smaller platform.

It is a multitasking and multithreaded operating system. Many processes can run

concurrently, they can communicate with each other and utilize multiple threads that
run internal to each process. The operating system has a file system compatible with
Microsoft Windows (technically, a FAT32 file system); it supports other file-system
implementations through a plug-in interface. It uses TCP/IP networking as well as
several other communication interfaces, such as serial, infrared and Bluetooth

Because of limited disk storage, no virtual memory is implemented. Symbian OS has

a pluggable messaging architecture – one where new message types can be invented
and implemented by developing modules that are dynamically loaded by the
messaging server.

Consider the way system calls work in Symbian OS. There are two types of system
call. An executive call makes a request for the kernel to execute an operation in
privileged mode on behalf of the user-space requestor. An executive call causes a
software interrupt, which is serviced by branching the operation into kernel code. The
interrupt is serviced and control is passed back to the user. There is a server that
protects kernel resources and requests to manipulate those resources need to go
through that server. Server requests are themselves
executive calls.

• The kernel structure of Symbian OS has a microkernel design. Minimal system

functions and data are in the kernel with many system functions spread out into
user-space servers. The servers get their jobs done by making executive calls into
the kernel when necessary.
• Symbian OS supports the use of virtual machines: the implementation of a
‘computer within a computer’. The implementation of the Java programming
language and the run-time environment needed to run Java is done through this
mechanism.
• Communication structures in Symbian OS are easily extended. Modules can be
written to implement anything from user-level interfaces to new protocol
implementations to new device drivers. Because of the microkernel design, these
new modules can be introduced and loaded into the operation of the system
dynamically.
• Symbian OS has been designed at its core with APIs specialized for multimedia.
Multimedia devices and content are handled by special servers and by a
framework that lets the user implement modules that describe new and existing
content and what to do with it.
 S60 UIQ

UI Framework Layer Java ME

Uikon FEP Base CONE

Application Services Layer

Messaging, Browsing, Data Synchronization etc.

OS Services Layer
Generic Communication Services Multimedi Connectivit
OS Telephony Short Link Networkin
a y
Services Services Services g & Services
Graphics

Base Services Layer

Kernel Services and Hardware Interface

Symbian OS Layer by Layer

Symbian operating system can be decomposed into layers, and layers as further
decomposed into blocks and sub-blocks and finally blocks are decomposed into
collections of individual components. Layers are the highest level abstraction in the
model; components are the lowest level abstraction, the fundamental units of the
model; blocks and sub-blocks decompose layers by functionality – roughly speaking,
by broad technology area.

The key concepts used by the system model are layers, blocks and sub-blocks,
component collections and components. Components provide the essential mapping
from the logical model to the concrete system. While layers, blocks and sub-blocks
are essentially logical concepts, components are physically realized in software,
typically consisting of multiple files in the operating system delivery (e.g. source code
files including test code; built executables including libraries; data and configuration
files; build files; and documentation). However, from the perspective of the model,
components are treated atomically and constitute the smallest units of architectural
interest.

UI Framework Layer

The topmost layer of Symbian OS, the UI Framework layer provides the frameworks
and libraries for constructing a user interface, including the basic class hierarchies for
user interface controls and other frameworks and utilities used by user interface
components.

The UI Framework layer also includes a number of specialists, graphics based

frameworks which are used by the user interface but which are also available to
applications, including the Animation framework and the Front End Processor (FEP)
base framework.

The user interface architecture in Symbian OS is based on a core framework called

Uikon and a class hierarchy for user interface controls called the control environment.
Together, they provide the framework which defines basic GUI behavior, which is
specialized by a concrete GUI implementation (for example, S60, UIQ or MOAP), and
the internal plumbing which integrates the GUI with the underlying graphics
architecture. Uikon was created to support easier user interface customization,
including ‘pluggable’ look-and-feel modules.

The Application Services Layer

The Application Services layer provides support independent of the user interface for
applications on Symbian OS. These services are divided into three broad groupings:
 1. System-level services used by all applications, for example the Application
Architecture.
2. Services that support generic types of application and application-like
services, for example personal productivity applications (vCard and vCal,
Alarm Server) and data synchronization services
3. Services based on generic but application-centric technologies, for example
mail, messaging and browsing (Messaging Store, MIME, HTTP Transport
Framework).

Applications in Symbian OS broadly follow the classic object-oriented Model–Viewer–

Controller (MVC) pattern. The framework level support encapsulates the essential
relationships between the main application classes (representing the application data
model, the views onto it, and the document and document user interface that allow it
to be manipulated and persisted) and abstracts all of the necessary underlying
system-level behavior.

The OS Services Layer

The OS Services layer is, in effect, the ‘middleware’ layer of Symbian OS, providing
the servers, frameworks, and libraries that extend the bare system below it into a
complete operating system.

The services are divided into four major blocks, by broad functional area:

1. Generic operating system services

o Example: Task Scheduler
2. Communications services
o Telephony Services
 Examples: GSM, CDMA, EDGE etc.
o Networking Services
 Examples: TCP/IP Stack Implementation, HTTP, SSL
o Short Link Services
 Examples: Bluetooth, Infrared, USB, OBEX
3. Multimedia and graphics services
o Examples: Window Server which provides Access to screen hardware
4. Connectivity services
o Supports Interaction with Desktop Host to:
 Perform Data Backup
 File Browsing and Transfer
 Software Installation from Desktop to Device
o

Together, these provide technology-specific but application independent services in the

operating system.

The Base Services Layer

The foundational layer of Symbian OS, the Base Services layer provides the lowest
level of user-side services. In particular, the Base Services layer includes the File
Server and the User Library. The microkernel architecture of Symbian OS places them
outside the kernel in user space. (This is in contrast to monolithic system
architectures, such as both Linux and Microsoft Windows, in which file system
services and User Library equivalents are provided as kernel services.)

Other important system frameworks provided by this layer include the ECom Plug-in
Framework, which implements the standard management interface used by all
Symbian OS framework plug-ins; Store, which provides the persistence model; and
the Cryptography Library.

The Kernel Services and Hardware Interface Layer

The lowest layer of Symbian OS, the Kernel Services and Hardware Interface layer
contains the operating system kernel itself, and the supporting components which
abstract the interfaces to the underlying hardware, including logical and physical
device drivers ‘variant support’, which implements pre-packaged support for the
standard, supported platforms (including the Emulator and reference hardware
boards).

In releases up to Symbian OS v8, the kernel was the EKA1 (Kernel Architecture 1)
kernel, the original Symbian OS kernel. In Symbian OS v8, the EKA2 (Kernel
Architecture 2) real-time kernel shipped for the first time as an option. From Symbian
OS v9, EKA1 no longer ships and all systems are based on the real-time EKA2 kernel

Java ME

In some sense, Java does not fit neatly into the layered operating system model.
Symbian’s Java implementation is based around:

• a virtual machine (VM) and layered support for the Java system which
complements it, based on the MIDP 2.0 Profile
• a set of standard MIDP 2.0 Packages
• an implementation of the CLDC 1.1 language, I/O, and utilities services
• a number of low-level plug-ins which implement the interface between CLDC,
the supported packages, and the native system.
Key Design Patterns of Symbian Operating System

Like any good architecture, the patterns repeat at multiple levels of abstraction and
in all corners of the system.

The Client–Server Model

Probably the most pervasive architectural pattern in Symbian OS is the structuring

client–server relationship between collaborating parts of the system. Clients wanting
services request them from servers, which own and share all system resources
between their clients.

In Symbian OS, all system resources are managed by servers. The kernel itself is a
server whose task is to manage the lowest level machine resources, CPU cycles and
memory. From the kernel up, this pattern is ubiquitous. For example, the display is a
resource managed by the Window Server; display fonts and bitmaps are managed by
the Font and Bitmap Server; the data communications hardware is managed by the
Serial Server; the telephony stack and associated hardware by the Telephony Server;
and so on all the way to the user-interface level, where the generic Uikon server (as
specialized by the production GUI running on the final system) manages the GUI
abstractions on behalf of application clients.

Asynchronous Services

Another widely used pattern is the use of asynchronous methods in client–server

communications. Typically, client–server interactions on Symbian platform are
asynchronous.

System responsiveness in a multitasking system (the impression that applications

respond instantly and switch instantly) depends on asynchronous behavior;
applications don’t wait to finish processing one action before they are able to handle
another.

The alternatives are blocking, or polling, or a combination of both. In a blocking

request (the classic Unix pattern), the calling program makes a system call and waits
for the call to return before continuing its processing. Polling executes a tight loop in
which the caller checks to see if the event it wants is available and handles it when it
is. (Polling is used by MS-DOS, for example, to fetch keystrokes from the keyboard.)

Blocking is unsatisfactory because it blocks others from accessing the system call
which is being waited on, while it is waiting. Polling is unsatisfactory because code
which is functionally idle, waiting for an event, is in reality not idle at all, but
continuously executing its tight polling loop. Blocking reduces responsiveness. Polling
wastes clock cycles, which on a small system like mobile phones translates directly to
power consumption and battery life.

The Plug-in Framework Model

The plug-in framework model is used pervasively in Symbian OS, at all levels of the
system from the UI Framework at the top to the lowest levels of hardware abstraction
at the bottom.

A framework is an enclosing structure. A plug-in is an independent component that

fits into the framework. The framework has no dependency on the plug-in, which
implements an interface defined by the framework; the plug-in has a direct, but
dynamic, dependency on the framework. On a small scale, this is what designing with
classes achieves: a class abstracts an interface and its expected behavior
encapsulates its implementation. Frameworks provide a mechanism for this kind of
abstraction and encapsulation at a higher level.

A framework in Symbian OS defines an external interface to some part of the system

(a complete and bounded logical or functional part) and an internal plug-in interface
to which implementers of the framework functionality (the plug-ins) conform. In
effect, the framework is a layer between a calling client and an implementation. In
the extreme case, a ‘thin’ framework does little more than translate between the two
interfaces and provide the mechanism for the framework to find and load its plug-ins.
A ‘thicker’ framework may do much more, providing plug-in interfaces which are
highly abstracted from the external visible client interface. Symbian OS contains
frameworks at both extremes and most points in between.

Because in Symbian OS a framework exposes an external interface to a complete,

logical piece of the system, most frameworks are also implemented as servers. The
plug-in model is used to structure the internal relationships within complex parts of
the system, to enable flexibility and extensibility. Flexibility in this context means run-
time flexibility and is particularly important when resources are constrained. The
ability to load the requested functionality on demand enables more efficient use of
constrained resources (objects which are not used are not created and loaded).
Extensibility is important too in a broader sense. The use of plug-ins enables the
addition of behavior over a longer timescale without re-architecting or re-engineering
the basic design.

As well as providing interface abstraction and separation from implementation, and

flexibility through decoupling, frameworks also provide a natural model for functional
extension. This approach is used for example by the telephony-server framework to
provide an open-ended design. The core framework supports generic telephony
functionality based around a small number of generic concepts. Framework
extensions implement the specialized behaviors which differentiate landline from
mobile telephony, data from voice, circuit- from packet-switched, GSM from CDMA,
and so on.

Symbian OS Kernel

The real-time architecture is essential for a system implementing a telephony stack,

which depends on critical timing issues, and is also becoming increasingly important
for fast, complex multimedia functionality. Together, phone and multimedia are
arguably the most fundamental drivers for any contemporary operating system. As
mobile phones, in particular, reach new levels of multimedia capability, to become
fully functional converged multimedia devices (supporting streamed and broadcast
images and sound, e.g. two-way streaming for video phone conferencing and
interactive broadcast TV), achieving true real-time performance has become an
essential requirement for a phone operating system. The real-time kernel allows
Symbian OS to meet that requirement.

The real-time kernel architecture also introduces important changes (in particular to
mechanisms such as interprocess communication) to support the new platform
security model introduced from Symbian OS v9.
UI Platforms

Symbian OS is an inherently GUI-centric operating system which ships without a GUI

of its own. Moreover it targets a market (wireless devices generally and mobile
phones in particular) in which the user interface is a critical competitive element.

User interface issues are particularly interesting because they highlight many of the
unique problems of the mobile phone market

Symbian supports (but does not provide itself) multiple UIs. Licensees either buy in
the platform pre-integrated and tested from a Symbian OS UI vendor such as S60 or
UIQ or they buy in the operating
system ‘headless’ and develop their own GUI.

The Symbian operating system does not provide the UI layer; instead it provides the
infrastructure (frameworks and primitives) for UI creation. Beneath the UI, the
common frameworks and the underlying services of the operating system itself
ensure substantial platform compatibility at the application-engine (i.e. application-
logic) level. Indeed applications can be targeted at the different available user
interfaces by customizing the application UI without changing the application engine.

A Symbian licensee either creates a bespoke user interface from the frameworks
(although this is not a trivial engineering effort, it is the option chosen by DoCoMo in
Japan for its FOMA platform, for example) or buys in a UI from a specialist vendor
(UIQ and S60).

Symbian OS on a Sony Ericsson phone or a Motorola phone with the UIQ GUI – the
P910 or P990, say, or the Motorola A1000 – looks and feels very different to Symbian
OS on a Fujitsu or Mitsubishi FOMA phone or to Symbian OS on a Nokia, Samsung or
LG phone with an S60 GUI. And yet the underlying operating system is the same and
the very same applications can run on all of these different phones, sharing identical
source code at the application-logic and data-model levels.

While Symbian OS is tightly integrated to the GUI which runs on top of it, by way of
the UI and application frameworks, it is designed to be GUI-neutral. For application
developers and from the application perspective, although Symbian OS applications
are intrinsically GUI in nature, applications are only loosely coupled to a particular
GUI variant, since the application model and the application-event loop are enshrined
in the operating system itself and in the UI Framework support, and not in the variant
user interface.

References

• The Symbian OS Architecture Sourcebook by Ben Morris

• Smartphone Operating System Concepts with Symbian OS by Michael J.
Jipping