Autosar Basics hand book_v1

AUTOSAR
Handbook
https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Prepared by: Eng.Keroles Shenouda

ENG. Keroles Shenouda
Index
Study
(RTOS) Basics
Study
AUTOSAR OS
Which is based on
OSEK/VDX
Study
AUTOSAR Basics
Study
Automotive
protocols/Models
(CAN, TTCAN, CANFD, LIN
and FlexRay)
Solve Technical
Exams/interview questions
This revision aims to cover all the topics which in the
Automotive embedded system.
It shows the steps which you should follow to be perfect
in the Automotive Embedded System
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system

Automotive
embedded system
(10 parts)
You should Study well the Following parts:
All the below topics materials are placed here:
https://www.facebook.com/groups/embedded.system.KS/permalink/8871
60458114320/
Automotive Embedded System Part 1 (RTOS Basics)
Automotive Embedded System Part 2 (OSEK-VDX) PART 1
Automotive Embedded System Part 5 (Introduction to AUTOSAR)
Automotive Embedded System Part 6 (AUTOSAR Application Layer)
Automotive Embedded System Part 7 (CAN)
Automotive Embedded System Part 8 (CANFD, TTCAN ,LIN and
FlexRay)
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Step 1
Study the
following
Parts
Step 2
validate you
are aware for
those
conclusion or
not
If you don’t have a time you just need to see the
Following C conclusion, if you already aware for
them so you can skip the step 1.
Note: you will find the conclusion in this revision

Automotive
embedded system
Solve the Corner questions/tricks for all the
covered C topics
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Step 3
Solve the C
Tricks/questions

RTOS Conclusion
Embedded System
Learn In Depth

Definitions
Bare metal
“Bare metal" means your application is accessing the silicon
chip directly without any intermediary like an OS.
The application is the only software that executes on the
microprocessor/microcontroller.
So we can considered that the Drivers is a bare metal Code and the
bios also.
Bare-Metal application
C - Code
OS Application
Write your application on the top of the Operating System.
On desktop computers, the selection of an operating system (OS) is
largely a matter of taste - Windows vs Apple vs Linux. There is
relatively little choice.
For an embedded system, the matter is much more complex. The
large number of options available reflect the wide diversity of
embedded applications.
OS
Application
OS
Drivers
• Linux Command
• Graphical GUI “ex.QT application”
• C/C++ app.
• RTOS Tasks
• Autosar SW Component
Embedded Linux
• Linux Kernel “Linux.org”
• Open embedded YOCTO
• Android
• Windows IOT
Embedded windows
RTOS
Autosar• Free RTOS
• μC/OS-III
• RTOS OS + BSW +RTE
Embedded Linux Drivers
RTOS Drivers
MCAl Layer

Hypervisors
Virtualization you can run
operating systems called guests,
inside a sandbox contained under the
control of another piece of software
(the hypervisor) that manages all
interaction of the guest toward
hardware. The hypervisor runs at a
more privileged level of hardware
access than the operating system
(OS) kernel (supervisor) and user
privilege of the guest OS
Operating System (OS)
System is called multitasking system and design
aspects include:
Exchanging/sharing data between tasks
Synchronizing tasks
Scheduling tasks
Also it provides a services:
–Process or task management
•Creation and deletion of user and system processes
–Memory management
•Includes tracking and control of which tasks are loaded into memory, monitoring memory, administer
dynamic mem
–I/O System management
•Interaction with devices done through a special piece of software called a device driver
•The internal side of that software is called a common calling interface (an application programmer's
interface, API)
–File system management
–System protection
–Networking
Memory Management
• In multiprogramming, OS decides which
process will get memory when and how much.
•Allocates the memory when the
process requests it to do so.
•De-allocates the memory when the
process no longer needs it or has been
terminated.
• Sometimes if the CPU hardware “MMU”
provides mapping between virtual and
physical addresses, the OS “memory
management” will manage the Virtual
memory for each task

Processor Management
OS decides which process gets the processor
when and how much time. This function is
called process scheduling.
Operating System does the following
activities for processor management.
•Keeps tracks of processor and status
of process. Program responsible for
this task is known as traffic controller.
•Allocates the processor (CPU) to a
process.
•De-allocates processor when
processor is no longer required.
Device Management (I/O System
management )
• OS manages device communication via
their respective drivers. Operating System
does the following activities for device
management.
•Keeps tracks of all devices. Program responsible for
this task is known as the I/O controller.
•Decides which process gets the device when and for
how much time.
•Allocates the device in the efficient way.
•De-allocates devices.
Kernel
The Kernel is the smallest portion of the OS
that provides these functions
• Scheduler
–Determines which task will run and when it will
do so
•Dispatcher
–Performs the necessary operations to start the
task
•Intertask or interprocess communication
–Mechanism for exchanging data and information
between tasks and processes on the same
machines or different ones

What is Real Time?
“not only depends upon the logical
correctness of the computation but also
upon the time at which the result is
produced.
 If the timing constraints of the system
are not met, system failure is said
A real time system is one in which the
correctness of the computations to have
occurred.” at specific timeline
Real Time:
Correct logic
With a specific
Timeline
Real Time System
 A system is said to be Real Time if it is
required to complete it’s work & deliver it’s
services on time.
 Example – Flight Control System
 All tasks in that system must execute on
time.
 Non Example – PC system
 There are types of Real Time System
Soft real time
Hard real time
• Soft real time
• Tasks are performed by the system as fast as
possible, but tasks don’t have to finish by
specific times
• Multitask based on Priority scheduling
• Ex. Multimedia streaming
25 frames per second on an average
• Hard real time
• Tasks have to be performed correctly and on
time
• Multitask based on Deadline scheduling
• Ex. Aircraft controller, Nuclear reactor
controller
Real-Time Operating
System (RTOS)
An RTOS provides an Abstraction Layer between
Application Software and Embedded Hardware
Key characteristic of an RTOS is that it has
deterministic behavior
Basic Services provided by a Real-Time Operating
System Kernel
“Real-time” means keeping deadlines, not speed
Advantages of RTOS in SoC design
•Shorter development time
•Less porting efforts
•Better reusability
Task
0
Task
1

Characteristics of an RTOS
• Reliability:
• Available and doesn’t fail.
• Predictability:
• Deterministic with small time variance.
• Performance:
• Fast enough.
• Compactness
• Small and efficient.
• Scalability
• Result of modularity and RTOS
configurations to be used in many
systems.
Foreground/Background Systems
• An application consists of an
infinite loop that calls modules
(that is,
functions) to perform the desired
operations (background).
• Interrupt Service Routines (ISRs)
handle asynchronous
events (foreground).
So Foreground is also called
interrupt level while background is
called task level
Background
Foreground
ISR ISR
ISR
(more
importa
nt)
1. Normal
program
execution
2. Interrupt
occurs
3. Processor
state saved
4. Interrupt routine runs
5. Interrupt routine
terminates
6. Processor state
restored
7. Normal
program
execution
resumes
Handling an Interrupt

Reentrancy
• A reentrant function is a
function that can be used
by more than one task
without cause of data
corruption.
• A reentrant function can be
interrupted at any time and
resumed at a later time
without loss of data.
• An error caused by a non-
reentrant function may not
show up in your application
during the testing phase
 non-reentrant
int temp; // global
function swap(int *x, int *y) {
temp = *x;
*x = *y;
*y = temp;
}
 reentrant
version
function swap (int *x, int *y) {
int temp; // local
temp = *x;
*x = *y;
*y = temp;
}
Non-
reentrant
function
Process or Task
• A task is usually implement in C by writing a function
• When a C function is executing, it is called a process or task
• So Task is not code
• Two tasks can be executing the same code simultaneously
• When a process is created, it is allocated a number f
resources by the OS, which may include:
• –Process stack
• –Memory address space
• –Registers (through the CPU)
• –A program counter (PC)
• –I/O ports, network connections, file descriptors, etc.
• These resources are generally not shared with other
processes
int x;
int Func() {
int y;
y = y + 1;
x = x + 1;
...
}
Task 1 Task 2

Tasks conclusion
 Each task thinks it has the CPU to itself
 Each task has its own stack space and its own set
of CPU registers
 Each task has a priority
 A task may well take the form of
 a sequence of initialisation code; followed by
 a loop which iterates forever (or until a flag is set to
exit it)
 Body of loop will contain application code
 A task calls functions which are preferably
reentrant:
 Can be safely called by more than one function at a
time
 Interrupting them does not corrupt their data
 Typically implemented using local variables
 Reusable and reentrant Code
Void task1()
{
// a sequence of
//initialisation code
While(1)
{
//application code
}
}
Context Switch (or Task Switch)
• When a multitasking kernel decides
to run a different task, it simply saves
the current task's context (CPU
registers) in the current task's
context storage area – it’s stack.
• Once this operation is performed,
the new task's context is restored
from its storage area and then
resumes execution of the new task's
code.
• This process is called a context
switch or a task switch. Context
switching adds overhead to the
application.
Task States
Waiting
Dormant Ready Running ISR
Task Create
Task Delete
Highest Priority Task
Task is Preempted
Task Pending EventsTask Gets Event
Task Delete
Interrupt
Int. Exit
Task Delete

Scheduling - types
• Non Real -time systems usually use Non-preemptive Scheduling
• Once a task starts executing, it completes its full execution
• Most RTOS perform priority-based preemptive task scheduling.
• Basic rules for priority based preemptive task scheduling
• The Highest Priority Task that is Ready to Run, will be the Task that Must be Running.
Non-preemptivepreemptive
Non-preemptive
• It is also called cooperative multitasking;
• tasks cooperate with each other to share the CPU.
• tasks decide for themselves when to give up the
CPU; when completed.
• The new higher priority task will gain control of
the CPU only when the current task gives up the
CPU.
• asynchronous events are handled using interrupts
• tasks still have an assigned priority
advantages:
- interrupt latency time is low
- less need to “guard” shared resources
-At the task level, non-preemptive kernels can also
use non-reentrant functions.
disadvantages:
- responsiveness is non-optimal & non-deterministic
- one task may lock-up system
Time
ISR
Low-priority Task
High-priority Task
ISR makes the
high-priority task ready
low-priority task
Relinquishes the CPU
(low priority task is finished)
Preemptive
• the highest priority task (ready) is given control
of the CPU
• current running task is suspended
• after an Interrupt Service Routine (ISR), the new
highest priority task is run
• Most commercial real-time kernels are
preemptive
advantages:
- responsiveness is optimal & deterministic
(Execution of the highest-priority task is deterministic)
-Task-level response time is minimized
disadvantages:
- shared resources must be properly guarded
-Should not use non-reentrant functions unless
exclusive access to these functions is ensured
Time
IS
R
Low-priority Task
High-priority Task
ISR makes the
high-priority task ready
high-priority task
Relinquishes the CPU

Scheduler Concepts
• CPU utilization : keep the CPU as busy as possible.
How much of CPU (usually in %) is in use ?
• Throughput : number of processes (# pf processes) that complete their
execution per time unit.
• Turnaround : total time between submission of a process and its completion.
(waiting + executing + IO Time)
• Waiting time : a mount of time a process has been waiting in the ready
queue.(task enters by System initially), then it is placed in “ready state” when
the conditions are met.
• Response time : amount of time it takes from when a request was submitted
until the first response is produced.
Scheduling Algorithms in
time-shared System
1. First-Come First-Served
2. Shortest Job First
3. Round Robin
4. Round-robin with priority
scheduling
First In First Out Algorithm
• Also known as First Come, First Served
(FCFS).
• It is the simplest scheduling algorithm.
• FIFO simply queues processes in the order
that they arrive in the ready queue
• It is non-preemptive
• scheduling overhead is minimal.
• Throughput can be low.
• This is considered as a very good algorithm
when few small tasks all with small
execution times
Shortest Job First Algorithm
• Also known as Shortest Job First (SJF).
• With this strategy the scheduler arranges
processes with the least estimated
processing time remaining to be next in
the queue.
• If a shorter process arrives during another
process 'execution, the currently running
process may be interrupted.
• This algorithm is designed for maximum
throughput in most scenarios.
• Starvation is possible, especially in a busy
system with many small processes being
run
• This algorithm can be
• Preemptive (Running task can be interrupted
by another task).
• Non Preemptive

Round-robin scheduling Algorithm
(time-slicing)
• Designed especially for time shared systems.
• Similar to first –come first-served, with
preemption added to switch between
process.
 tasks with the same priority are only allowed to
run for a predetermined time period, “a
quantum” This is also called time slicing.
• not necessarily supported by all preemptive
kernels
• microC/OS-II does not support round-robin
• The Round Robin Algorithm is slightly modified by assigning priority to all tasks.
• Highest priority task can interrupt the CPU so it can be executed.
Round-robin with priority
scheduling
Scheduling - priorities
• static
• the priority of a task is set at compile time and does not change during application execution
advantage:
all timing constraints can be known at compile time
disadvantage:
may get priority inversion
• dynamic
• each task can change its priority during execution
advantage:
useful in avoiding priority inversion
disadvantage:
not easy to guarantee schedulability

Priority Inversions
• Low-priority process acquires
lock, blocks higher-priority
process
• Priority inheritance temporarily
raises process priority
• Difficult to analyze
Priority Inheritance Solution
Task 1 (high)
Task 2 (medium)
Task 3 (low)
1 2 3 4 5 6
 In a kernel that supports priority
inheritance,
 As soon as task 1 wants the resource
(point 3) locked by task 3, task 3 is
temporarily promoted to task 1’s
priority so that it can continue running
until it releases the resource (point 4)
 Then, task 1 becomes ready because it
can acquire the resource released by
task 3.
 Task 1 releases the resource at point
5, but keeps running also task 2 is
ready, because it has the highest
priority
 Finally at point 6, task 1 finishes and
task 2 can run. Task 3, with the lowest
priority, waits.
 NB Task 2 could have become ready at
point 2 or any after thereafter, with
no difference in outcome..
Scheduling - the “tick” or quantum
 A hardware Timer generates interrupts at
a regular interval
 10 -- 1000 Hz; usually derived from power line
frequency
 Used to provide delays and timeouts
 The ISR for a clock tick calls a kernel
service to signal a tick. This may well cause
a context switch
 A higher priority task may have become ready to
run in the interim
 In “round robin” scheduling, tasks of equal priority
get a fixed number of ticks’ CPU time than go to
the back of the queue
 The clock interrupt has higher priority than
all tasks (because it is an interrupt) but
lower priority than other interrupts.

Two shared Resource Control
the mutex = MUTual
EXclusion.
the semaphore
Resource
A resource is any entity used
by a task. A resource can thus
be an I/O device such as a
printer, a keyboard, a display,
etc. or a variable, a structure,
an array, etc.
Shared Resource
A shared resource is a
resource that can be used by
more than one task. Each task
should gain exclusive access
to the shared resource to
prevent data corruption. This
is called Mutual Exclusion.
mutex
• A critical section is a piece of code (part of a
function) from which the access to the shared
resource must be atomic. At a certain moment in
time, one and only one critical section is allowed to
access the shared data
• The mutex implements two operations:
• acquire: enter the critical section, or sleep if another
task has already acquired the mutex, and
• release: leave the critical section. Other tasks now have
the possibility to acquire the mutex.
• The concept of ownership is very important here: the task
that acquired the mutex must release it as well.
• techniques to address mutual exclusion include:
• disabling/enabling interrupts
• disabling scheduling
• performing test-and-set operations (indivisibly)
• using semaphores

Mutual Exclusion
Disable interrupts
Mechanism
• Demand: exclusive use of a resource
• Disable interrupts
• Used on critical sections of
code
• disabling/enabling interrupts
• used to access a few variables or small data
structures
• used when the process time is minimal
• affects interrupt latency
• you should not disable interrupts for any longer
than the kernel does
• in C/OS-II:
OS_ENTER_CRITICAL( );
… // you can access shared data here
OS_EXIT_CRITICAL( ):
Disadvantages:
1. Disabling interrupt for long time harm the
system response
And the RTOS Kernel Itself
Mutual Exclusion
Disable preemption (Task
Switching) Mechanism
disabling scheduling
instead of disabling all maskable
interrupts, you may just want to
disable the scheduler
an interrupted task is
returned to, not necessarily
the highest priority task
implies that data is not shared with
the ISRs
performing test-and-set operations (indivisibly)
perform test-and-set operations (indivisibly)
two tasks may agree that to use a
common resource, they must first check a
global variable
while it is being checked, and before it is
set, by one task, it must be made
inaccessible by the other
this can be achieved by:
disabling interrupts (above) or
some processors now support a
single TAS instruction
Kindly Note: DPRAM test-and-set instructions can
work in many ways
When CPU 1 issues a test-and-set instruction, the
DPRAM first makes an "internal note" of this by
storing the address of the memory location in a
special place. If at this point, CPU 2 happens to issue a
test-and-set instruction for the same memory
location, the DPRAM first checks its "internal note",
recognizes the situation, and issues a BUSY interrupt,
which tells CPU 2 that it must wait and retry.

semaphores
• a protocol mechanism to control
access to shared resources, signal
the occurrence of an event or
allow two tasks to synchronize
• one analogy is that in order for a
task to use a resource it must first
draw a key for it
• if the key(s) is in use, the task
suspends
• wait on (pend) & signal (post)
semaphore
• two types of semaphores:
• binary and counting (general)
task 2
task 1 1. pend
4. post
Printer
2. pend
6. post
5. “my name is
task 2”
3. “my name is task 1”
Encapsulated semaphores
Principle:
task does not have to control semaphore
Resource controls the semaphore
Typical: driver of the resource solves
semaphores
Release of a semaphore is done through a
timeout
eg. Network card, serial port, ...
Advantages:
tasks just use the driver
programmer does not have to deal with the
semaphores
Deadlock
Two tasks waiting for each
others semaphore
most kernels allow you to specify a
timeout when acquiring a
semaphore (with error code)

Synchronisation
 Synchronisation between tasks
 Synchronisation between tasks and ISR
 How ?
 Use of semaphores
 "unilateral rendezvous"
 semaphore signals an event (flag,
NOT a key)
Synchronization : Use of
semaphores
• one task can be synchronized
with another (no data
transferred) by using a
semaphore
• the semaphore is a flag
signaling the occurrence of an
event (vice a key for mutex)
• in this case, the semaphore is
initialized to 0
Task 2 Task 1
2. Post 1. Pend
"bilateral rendezvous"
• bilateral rendezvous - two tasks can
be synchronized with each other by
using two separate semaphores
Task 2 Task 1
1. Signal Task 2
2. wait for signal from task 2
4. wait for signal from task 1
3. Signal Task 1

Event Flags
• When ?
• A task has to synchronise with multiple
events
• Disjunctive synchronisation
• logical OR
• synchronisation if one of the events
occurred
• Conjunctive synchronisation
• logical AND
• synchronisation if all
events occurred
Multiprogramming - A computer running more than one
program at a time (like running Excel and Firefox
simultaneously)
Multiprocessing - A computer using more than one
CPU at a time
Multitasking - Tasks sharing a common resource (like 1
CPU)

AUTOSAR OS based on
OSEK-VDX Standard
Conclusion
Embedded System
Learn In Depth

AUTOSAR OS
• AUTOSAR OS is the specification of an OS
kernel for AUTOSAR architecture.
• It is based on OSEK/VDX OS :
• Software counters
• Schedule Tables
• Global time synchronization
• Stack monitoring
• OS Applications
• Protection mechanisms
• the main improvement is the addition of
configurable mechanisms for error detection
in the kernel (called “protection facilities”)
This rectify the OSEK/VDX OS inability to
support critical systems
OSEK/VDX OS
Services of OSEK:
• Task services
• Synchronization services (events)
• Mutual exclusion services
(resources)
• One-shot and periodical services
(counters and alarms)
• Interrupt management services
• Communication services
• System services and error
management

Scheduling modes
“Full preemptive”:
All tasks are preemptable.
Full preemptive scheduling will put the running
task into the ready state, as soon as a higher-
priority task has got ready. The task context is
saved so that the preempted task can be continued
at the location where it was preempted.
EX: task T2 with the lower priority does not delay
the scheduling of task T1 with higher priority.
“Full non preemptive”:
All tasks are non-preemptable
the non preemptable section of a
running task with lower priority delays
the start of a task with higher priority up
to the next point of rescheduling
EX: task T2 with the lower priority delays
task T1 with higher priority up to the
next point of rescheduling (in this case
termination of task T2).
“Mixed”:
Each task may be configured as
preemptable or non-preemptable
It is the most flexible model.
For instance, a very short task (in
execution time) may be configured as
non-preemptable because the context
switch is longer than its execution.
Processing Levels
The OSEK operating system enables a
controlled real-time execution of
several processes which appear to run
in parallel
Entities which are competing for the
CPU are:
Interrupt service routines
Tasks
OSEK defines three processing levels:
Interrupt level
Logical level for scheduler
Task level
Priority rules:
Interrupts have precedence
over tasks

Tasks in OSEK
• Tasks are « active » elements of the application
• 2 categories of tasks exist in OSEK/VDX:
Basic tasks
Extended tasks
A basic task is a sequential C
code that must terminate
The task that are able to wait
for an event are called
Extended tasks
Tasks’ services
TASK(myTask)
{
//Task’s instructions
…
//Task_Service API
}
Oil parameters

Events in OSEK-VDX
An event is like a flag that is raised to signal something just happened.
An event is private: It is a property of an Extended Task. Only the owning task may wait for the event.
It is a N producers / 1 consumer model
Any task (extended or basic) or Interrupt Service Routines Category 2 may invoke the service
which set an event.
One task (an only one) may get the event (ie invoke the service which wait for an event.
An Extended Task may wait for many events simultaneously
The first to come wakes up the task.
an event corresponds to a binary mask: 0x01, 0x02, 0x04, ...
Events’ services
StatusType SetEvent(TaskType <TaskID>, EventMaskType <Mask>);
This service is not blocking and may be called from a task or an ISR2
StatusType ClearEvent(EventMaskType <Mask>);
The events selected by <Mask> are cleared.
should be called by the owning task (only);
StatusType GetEvent(TaskType <TaskId>, EventMaskRefType event);
The event mask of the task <TaskId> is copied to the variable event
(A pointer to an EventMaskType is passed to the service);
Non-blocking service, my be called from a task or an ISR2
StatusType WaitEvent(EventMaskType <EventID>);
Put the calling task in the WAITING state until one of the events is set.
May be called by the event owning (extended) task only;
Blocking service.
Oil parameters
Synchronization of tasks: A task
should be able to wait an external event (a
verified condition).
To implement this feature, OSEK uses
events.
Task’s model is modified to add a new
state: waiting.
The task that are able to wait for an event
are called Extended tasks
NOTE:

Interrupts (ISR Management) in OSEK-VDX
ISR category 1 The ISR does not use
an operating system service8. After the
ISR is finished, processing continues
exactly at the instruction where the
interrupt has occurred, i.e. the interrupt
has no influence on task management.
ISRs of this category have the least
overhead.
ISR category 2 The OSEK operating system
provides an ISR-frameto prepare a
run-time environment for a dedicated user
routine. During system generation the
user routine is assigned to the
interrupt.
2 kinds of interrupts (Interrupt Service Routine or ISR) are defined in OSEK.
Level 1 interrupts
are very fast;
depends on the hardware capabilities of the micro-controller;
are not allowed to do a system call;
usually difficult to port to another micro-controller;
Level 2 interrupts
are not as fast as level 1 interrupts
are allowed to do some system calls (activate a task, get a resource, ...)
Are not allowed to do system calls;
• ISR1 are ignored by the operating
system and defined as classical
interrupts:
• Init interrupt registers of the
hardware peripheral;
• Init the related interrupt mask
• Do not touch the other interrupt
masks (which are managed by the
operating system).
May (must?) do system calls (activate a task, get
a resource, …)
• Roughly the same behavior as a task
• they have a priority (greater than the higher
priority of tasks).
ISR2 priority is a logical one and not be related
to the hardware priority level.
• they have a context (registers, stack, …)
• In addition an ISR2
• is associated to a hardware interrupt
(triggered by an event)
To use an ISR2, it is necessary to
• declare it in the OIL file with the
interrupt source identifier (depends on the
target platform) to indicate where the interrupt
handler is installed;
• initialize the related interrupt registers
of the peripheral which will trigger
the interrupt.

ISR2
ISR1
Example on ISR2

Counters and Alarms in OSEK-VDX
Goal:
perform an “action” after a number of “ticks” from an hardware device:
Counter
Activate a taskSet an event
alarm-callback routine
The counter is an abstraction of the hardware
“tick” source (timer, interrupt source, ...)
The “tick” source is heavily dependent of
the target platform;
The counter is a standard component;
At least one counter is available:
SystemCounter
No system call to modify the
counters.
Their behavior are masked by the
alarms.
A hardware interrupt must be
associated to a counter
• An alarm is connected to a counter an
performs an action.
• An alarm is associated to 1 counter
• A counter may be used for several
alarms
• When the counter reach a value of
the alarm (CycleTime, AlarmTime),
the alarm expires and an action is
performed:
• Activation of a task;
• Signalization of an event;
• alarm-callback routine
Alarms’ services

shared resources in OSEK-VDX
OSEK/VDX offers a RESOURCE mechanism with 2
associated system calls:
GetResource
ReleaseResource
• StatusType GetResource ( ResourceType <ResID> ) ;
• A task that « own » the resource may not be preempted
by another task that will try to get the resource.
StatusType ReleaseResource ( ResourceType <ResID> ) ;
OIL Description of a resource
RESOURCE resA {
RESOURCEPROPERTY =
STANDARD;
};
TASK myTask {
PRIORITY = 2;
AUTOSTART = FALSE;
ACTIVATION = 1;
SCHEDULE = NON;
RESOURCE = resA;
STACKSIZE = 32768;
};
“RES_SCHEDULER” Resource
STANDARD Resource
• There is a resource that is always available for tasks and is the
RES_SCHEDULER.
• By using this resource a PREEMPTIVE task can block any other while it
is performing an action during which does not want to be interrupted.
• In this way it is possible for a PREEMPTIVE task transforming itself during the
use of this resource into a NON PREEMPTIVE task.
Internal Resources
• OSEK-OS offers the possibility of defining internal resources.
• These resources are not handled and released by using GetResource
and ReleaseResource but they are automatically reserved and released by
the system at Begin and finish a task.
• By using internal resources the user is allowed to create task groups
cooperatives which use the same internal resource. In this way all the tasks that
use the same internal resource behave each other as NON PREEMPTIVE.

Linkead os Resources
• Linking two resources is linked
internally so that for the operating
system They have different
names but they are treated as if
they were the same resource.
• In this Example, "Using Linked
Resources" you can see two TaskA tasks
and TaskB using respectively Res1 and
Res2. The operating system treats both
resources as if they were the same.
Tasks group
This feature allow to mix non-preemptable tasks and preemptable tasks.
In the same group all the tasks are seen as non-preemptable by the other
tasks of the group.
A task having a higher priority of all the tasks of the group (and not part of the
group) may preempt any task of the group.
This feature uses an internal resource for each group:
The internal resource is got automatically when the task start to run;
The internal resource is released automatically when the task terminates;
An internal resource may not be reference with GetResource() or
ReleaseResource().

Hook Routines in OSEK-VDX
The hookroutines are functions implemented by the user that the operating
system will call in specific situations.
They are optional and can be used to add some specific management desired by the user
in the following situations:
StartupHook: it is called during the initialization of the operating system, before
being completed.
ShutdownHook: it is called at the end of the shutdown of the operating system.
PreTaskHook: is called before proceeding to execute a task. •
PostTaskHook: is called when the execution of a task ends.
ErrorHook: it is called in case any of the interfaces of the operating system
returns a value other than E_OK.
• Features
• OSEK proposes dedicated routines (or functions) to allow the user to «hook » an action at important
stages in system calls.
• “hook routines” are/have:
• called by the operating system;
• a priority greater than all tasks;
• not interrupted by ISR2 (presented after);
• a standardized interface;
• able to call a subset of the operating system services.
Oil file

AUTOSAR Basics
Embedded System
Learn In Depth

Automotive industry

AUTOSAR Process

AUTOSAR Layered Architecture
What is the AUTOSAR standard
and why is it created?
AUTOSAR is standardized software architecture developed in
cooperation between car manufacturers originally intended
for the automotive industry but is steadily gaining interest
from other industries as well.
AUTOSAR was developed with the intention of being able to
handle the increased complexity in today’s automotive
industry and to decouple software from hardware.
Also Integration of functional modules from multiple
suppliers
Software updates and upgrades over vehicle lifetime
Consideration of availability and safety requirements

AUTOSAR Basic Software Module (BSW)

CAN Communication Stack

Diagnostic Communication Manager (DCM)

AUTOSAR Memory Stack

System Services on BSW

AUTOSAR
Benefits

Classic Platform vs. Adaptive Platform
Adaptive AUTOSAR Use Cases

AUTOSAR System Design Process
Application Layer
The purpose of the application
layer is to provide the actual
functionality of the system.
This is done through the usage of
SWCs, which are components
containing software.
SWC
An application consists of one or
more SWCs based in the
Application layer. In order for
SWCs to communicate with each
other they use the virtual
functional bus (VFB). From a
SWC’s point of view all it sees is
the VFB and not the hardware
dependent BSW and the hardware
itself

SWC elements
Ports
PPort  provide port
Rport  require port
PRPort  provide require port
Internal Behavior
Runnables
RTE Events
InterrunnableVaribales
Implementation (source or object code)

Runnable Entities
Each Atomic Software Component consists of at least one Runnable Entity that executes code.
A Runnable Entity serves to structure the Software Component's functionality.
Each Runnable Entity can be scheduled or triggered individually and independently from other
Runnable Entities.
Each Runnable Entity should be triggered by at least one Event.
Runnable Entities are implemented by
C-functions

(Mapping SWC to OS tasks )

System modeling
Used BSW Modules
You should
configure all
those modules,
but we just will
focus on the
AUTOSAR OS

Automotive
Modules/Protocols
Embedded System
Learn In Depth

Data Frame

What does CAN-FD bring?
• Improvements on the CAN protocol
• CAN-FD is based on the CAN 2.0 specification
• Adds new features on top
• Arbitration phase –same as standard CAN
• Data phase –bitrates higher than 1Mbit/s possible (up to ~8Mbit/s)
• Support for larger data payloads –up to 64 bytes/message
• System cost is similar to standard CAN
Four data frame formats:
Standard CAN –11 bit ID and fixed bit rate
Extended CAN–29 bit ID and fixed bit rate
Standard CAN-FD –11 bit ID and flexible bit rate
Extended CAN-FD–29 bit ID and flexible bit rate
Error frames –identical to CAN error frames
Remote frames –only possible with standard CAN format
Time-Triggered CAN (TTCAN)
It was developed due to the demand for time-triggered communication in real-
time applications
Since that the CAN depends on event-triggered
Proposed by the CAN in Automation (CiA) group and Bosch and currently specified in the ISO 11898-
4 standard

Local Interconnect Network (LIN)
Used for Several sub-systems are fit for this performance level: sun-roof,
rain-detector, seats, doors, windscreen.
Single Wire Implementation
Single Master/Multiple Slave
Based on common UART/SCI
No arbitration necessary
Self Synchronization
Designed for low-cost automotive networks
Security of transmitted data (CRC)
Speed up to 20 kbit/s

• The FlexRay communication cycle is the fundamental
element of the media-access scheme within FlexRay. The
duration of a cycle is fixed when the network is designed,
but is typically around 1-5 ms. There are four main parts to
a communication cycle:
FlexRay

References
https://www.autosar.org
Embedded Microcomputer Systems Real Time Interfacing Third Edition Jonathan W. Valvano
University of Texas at Austin.
MicroC/OS-II the real-time kernel second edition jean j.labrosse.
RTOS Concepts http://www.embeddedcraft.org.
OSEK/VDX Operating System Specification 2.2.3
AUTOSAR Layered Software Architecture
The Trampoline Handbook release 2.0
Trampoline (OSEK/VDX OS) Test Implementation -Version 1.0, Florent PAVIN ; Jean-Luc BECHENNEC
• Trampoline:an open platform for (small) embedded systems based on OSEK/VDX and
AUTOSAR
http://trampoline.rts-software.org/
Jean-Luc Béchennec1;2, Sébastien Faucou1;3
1IRCCyN (Institute of Research in Communications and Cybernetics of Nantes)
2CNRS (National Center for Scientific Research) / 3University of Nantes
10th Libre Software Meeting
Real Time Systems (RETSY)
Jean-Luc Béchennec - Jean-Luc.Bechennec@irccyn.ec-nantes.fr
Sébastien Faucou - Sebastien.Faucou@univ-nantes.fr
jeudi 12 novembre 15
AUTOSAR Specification of Operating System V5.0.0 R4.0 Rev 3
OSEK - Basics http://taisnotes.blogspot.com.eg/2016/07/osek-basic-task-vs-extended-task.html
OSEK OS Session Speaker Deepak V.
M.S Ramaiah School of Advanced Studies - Bangalore 1
Introducción a OSEK-OS - El Sistema Operativo del CIAA-Firmware
Programación de Sistemas Embebidos
MSc. Ing. Mariano Cerdeiro
Introduction to AUTOSAR, Stephen Waldron, Vector webinar Wednesday 7th May
2014
https://vector.com/portal/medien/cmc/events/Webinars/2014/Vector_Webinar_AU
TOSAR_Introduction_20140507_EN.pdf
Introduction to AUTOSAR, Stephen Waldron, Vector webinar Tuesday 5th May 2015
https://vector.com/portal/medien/cmc/events/Webinars/2015/Vector_Webinar_AU
TOSAR_Introduction_20150505_EN.pdf
Automatic Generation of AUTOSAR Software Component Descriptions
Study Thesis in Computer Sciences by Christopher Mutschler
https://www2.informatik.uni-erlangen.de/EN/teaching/thesis/download/i2S00428.pdf
AutoSAR Overview FESA Workshop at KTH 2010‐04‐12
Prof. Jakob Axelsson
http://www.artist-
embedded.org/docs/Events/2010/FESA/slides/3_Autosar_Axelsson.pdf

AUTOSAR – An open standardized software architecture for the automotive industry Simon
Fürst, BMW 1st AUTOSAR Open Conference & 8th AUTOSAR Premium Member Conference
October 23rd, 2008, Cobo Center, Detroit, MI, USA
http://st.inf.tu-dresden.de/files/teaching/ws08/ase/03_AUTOSAR_Tutorial.pdf
Institutionen för systemteknik Department of Electrical Engineering Examensarbete
Implementation of CAN Communication Stack in AUTOSAR Examensarbete utfört i Datorteknik
vid Tekniska högskolan vid Linköpings universitet Av Johan Alexandersson och Olle Nordin
http://liu.diva-portal.org/smash/get/diva2:822343/FULLTEXT01.pdf
Applying AUTOSAR in Practice Available Development Tools and Migration Paths Master Thesis, Computer
Science Authors: Jesper Melin
http://www.idt.mdh.se/utbildning/exjobb/files/TR1171.pdf
Freescale AUTOSAR Software Overview.pdf
Introduction to the Controller Area Network (CAN)
CAN Learning From Vector
https://elearning.vector.com/index.php?&wbt_ls_seite_id=490352&root=378422&seite=vl_can_intro
duction_en
AUTOSAR Method, Vector Webinar 2013-04-17
https://vector.com/portal/medien/cmc/events/Webinars/2013/Vector_Webinar_AUTOSAR_Method_20130417.pdf
AUTOSAR Configuration Process - How to handle 1000s of parameters Vector Webinar 2013-04-19
https://vector.com/portal/medien/cmc/events/Webinars/2013/Vector_Webinar_AUTOSAR_Configuration_Process
_20130419_EN.pdf
AUTOSAR Runtime Environment and Virtual Function Bus, Nico Naumann
https://hpi.de/fileadmin/user_upload/fachgebiete/giese/Ausarbeitungen_AUTOSAR0809/NicoNaumann_RTE_VFB.
pdf
The AUTOSAR Adaptive Platform for Connected and Autonomous Vehicles, Simon Fürst, AUTOSAR
Steering Committee 8th Vector Congress 29-Nov-2016, Alte Stuttgarter Reithalle, Stuttgart, Germany
https://vector.com/congress/files/presentations/VeCo16_06_29Nov_Reithalle_Fuerst_BMW.pdf
A Review of Embedded Automotive Protocols, Nicolas Navet1, Françoise Simonot-Lion2 April 14, 2008
https://www.realtimeatwork.com/wp-content/uploads/chapter4_CRC_2008.pdf
AUTOSAR Adaptive Platform
https://vector.com/conference_india/files/presentations/Day1/3_AUTOSAR%20Adaptive%20Platform.pdf
CAN Bus Protocol
By Abhinaw Tiwari CSE-12010330
Basics of In-Vehicle Networking (IVN) Protocols
TTCAN Time Triggered CAN
http://www.cse.chalmers.se/~svenk/mikrodatorsystem/lectures/TTCAN_ppt.pdf
Automotive Communication Network Trends
Renesas Electronics America Inc.
https://elearning.renesas.com/pluginfile.php/355/mod_folder/content/0/DevCon_On-the-
Road/DevCon_OnSite/Automotive/Automotive_Communication_Network_Trends.pdf?forcedownload=1

http://article.sapub.org/pdf/10.5923.j.ajsp.20110102.07.pdf
https://vector.com/portal/medien/cmc/events/Webinars/2014/Vector_Webinar_IntroductionToLIN_20140930_EN.p
df
http://www.aut.upt.ro/~pal-stefan.murvay/teaching/nes/Lecture_1_Data_Communications_Basic_Concepts.pdf
http://www.aut.upt.ro/~pal-stefan.murvay/teaching/nes/Lecture_3_4_The_Controller_Area_Network_CAN.pdf
http://www.aut.upt.ro/~pal-stefan.murvay/teaching/nes/Lecture_05_CAN-FD.pdf
http://www.aut.upt.ro/~pal-stefan.murvay/teaching/nes/Lecture_06_CAN_Higher_Layer_Protocols.pdf
http://www.aut.upt.ro/~pal-stefan.murvay/teaching/nes/Lecture_7_Local_Interconnect_LIN.pdf
https://s3.amazonaws.com/ppt-download/theflexrayprotocol-140622084508-phpapp01.pdf?response-content-
disposition=attachment&Signature=a%2Be2MbDNPo5MZsGPTBpzmD%2FiN%2F4%3D&Expires=1514984564&AWSAcc
essKeyId=AKIAJ5J46ODGN4IB2ZXQ
http://www.ann.ece.ufl.edu/courses/eel6935_11fal/slides/Topic2-Network_FlexRay_20111013.ppt
http://www.autosar.org/about/technical-overview/ecu-software-
architecture/autosar-basic-software/
http://www.autosar.org/standards/classic-platform/
https://automotivetechis.files.wordpress.com/2012/05/communicat
ionstack_gosda.pdf
https://automotivetechis.files.wordpress.com/2012/05/autosar_ppt
.pdf
https://automotivetechis.wordpress.com/autosar-concepts/
https://automotivetechis.files.wordpress.com/2012/05/autosar_exp
_layeredsoftwarearchitecture.pdf
http://www.slideshare.net/FarzadSadeghi1/autosar-software-
component
https://www.renesas.com/en-
us/solutions/automotive/technology/autosar/autosar-mcal.html
https://github.com/parai/OpenSAR/blob/master/include/Std_Types.
h

RTOS Questions
Embedded System
Learn In Depth

Kindly you can find the Following Useful Embedded materials
On the internet (not prepared by me)

Embedded C,RTOS interview questions
with answers
1) What is RTOS and why do we go for it?
RTOS sheludes execution in a timely manner,manages system resources and provides a
consistent foundation for developing application code.
Application code designed for RTOS could be ranging from simple digital stopwatch to complex
aircraft navigation systems.
RTOS differs from the GPOS by
Task scheduling : RTOS like vxWorks,neclueos, uC/OSII uses a strict scheduling algorithms (like pre-
emptive scheduling) that makes the tasks meet their deadline to get the job done.
The sheduler decides which task run when by knowing its priorities.Whereas In a GPOS, the
scheduler typically uses a "fairness" policy that offers no assurances that high-priority, time-critical
tasks will execute in preference to lower-priority tasks.This policy is maintained to obtain the
overall output by the desktop pc or server pc.
2) What are the different types of semaphores in vxworks RTOS? Which is the fastest?
VxWorks supports three types of semaphores.
1) Binary 2) mutual exclusion, and 3)counting semaphores.
Fastest : Binary semaphore.
3. What is priority inversion ? why priority inversion occurs?
Tasks in RTOS's communucates between them via IPC source semphores for synchornization.
The situation priority inversion occurs when a higher priority taks is ready to run but it is waiting
for a shared resource that is to be released by a lower priority task currently running .Now higher-
priority task is pending on the resource and it has to wait until the lower priority task to finish.
4. What are the solutions for priority inversion ?
1) Priority inheritance
2) Priority ceiling
5. What is super loop ?
Super loop is the infinite loop that runs all the time because , most of the embedded systems has
no OS in it to return to application.
//Super loop example
while(true)
{
//all other code
}

//or
for(;;)
{
}
//or
label:
//This is is tricky assembly version
goto label:
6) What is the difference between Structure and union? Where do we use union?
When a structure is defined the compiler allocates memory for all of its member variables with
necessary alignment .Whereas for unions the compiler allocates memory for the highest the union is
equal to the biggest size of member from the union member variable list.union can only store
information in one field at any one time.
#include <stdio.h>
struct mStruct
{
char name[10];
int age;
float height;
};
union mUnion
{
char name[15];
int age;
float height;
};
int main(void)
{
union mUnion uTest;
struct mStruct sTest;
strcpy(sTest.name,"sTest");
sTest.age = 20;
sTest.height = 6.1;
strcpy(uTest.name ,"uTest");
uTest.height = 6.0;
uTest.age = 20;
printf("n");
printf("sizeof(uTest) = %d ,sizeof(sTest) = %d
n",sizeof(uTest),sizeof(sTest));

printf("uTest.age = %d , uTest.height = %f , uTest.name =
%sn",uTest.age, uTest.height, uTest.name);
printf("sTest.age = %d , sTest.height = %f , sTest.name =
%sn",sTest.age, sTest.height, sTest.name);
printf("n");
}
7) Convert number 2 --> 37 without using any other operator but bitwise ?
Answer:
int x = 2;
printf("X before :%dn",x);
x = (x<<x<<x) | (x<<x<<x) | x<<!!x | !!x ;
printf("X After :%dn",x);
8) Set , Get , Clear ,Toggle , Display Bits ?
// Display Every bits in a int number
void displayBits(int data)
{
int dataSize = 1<<sizeof(data);
int count = 0;
for (count = dataSize;count >= 0; count--)
{
printf("%d",(testBit(data,count)));
}
}
// test a bit if it is zero or one
int8_t testBit(int8_t value,int whichBit)
{
int mask = 1 << whichBit;
if (value&mask)
{
return TRUE;
}
else return FALSE;
}
// Set a bit to one
int8_t setBit(int8_t result, int whichBit)
{
return (result |= (1<<whichBit));
}
// toggle a bit
int8_t toggleBit(int8_t result, int whichBit)
{
return (result ^= (1<<whichBit));

}
/* Clear a bit to zero */
int8_t clearBit(int8_t result, int whichBit)
{
return (result &=~ (1<<whichBit));
}
RTOS / General OS questions
Difference between mutex and semaphore
mutex acquire and release happens in the same task. we use it to protect our critical section... and with
special features like priority inheritance, task deletion safety
however binary semaphores are not just used for critical section protection but also for process
synchronization....
meaning like raising an event so that the pending tasks wakes the moment the semaphore is available
isr will release a semaphore and a task waiting for it will unpend
so we can serialize the threads or tasks
1. what is a non re-entrant code?
-Re entrant code is code which does not rely on being executed without interruption before completion.
Reentrant code can be used by multiple, simultaneous tasks. Reentrant code generally does not access
global data. Variables within a reentrant function are allocated on the stack, so each instance of the
function has its own private data. Non-reentrant code, to be used safely by multiple processes, should
have access controlled via some synchronization method such as a semaphore.
2. how is RTOS different from other OS?
- A RTOS offers services that allow tasks to be performed within predictable timing constraints
3. Is unix a multitasking or multiprocessing operating system? whats the difference between the
two?
- unix is a multitasking operating system, multiprocessing means it can run on multiple processors, the
multiproceesing os coordinates with multiple processors running in parallel.
4. what is a core dump?
- A core dump is the recorded state of the working memory of a computer program at a specific time,
generally when the program has terminated abnormally
- includes the program counter and stack pointer, memory management information, and other
processor and operating system flags and information

- a fatal error usually triggers the core dump, often buffer overflows, where a programmer allocates too
little memory for incoming or computed data, or access to null pointers, a common coding error when
an unassigned memory reference variable is accessed.
5. what is stack overflow and heap overflow?
- stack overflow occurs when when the program tries to access memory that is outside the region
reserved for the call stack
- call stack contains the subroutines called, the local variables
- overflow occurs when too many functions are called,huge amount of local variables are allocated
6. windows also has multiple processes has process priotities switches between multiple process, how
RTOS is different from that?
- RTOS has predictable timing constranints
7. how will u create a process in UNIX or our OS OSE?
- We can use the fork system call to create a process in UNIX and in OSE the system call create_process
is used.
8. what is a flat memory model and a shared memory model?
- in a flatmemory model the code and data segment occupies single address space.
- in a shared model the large memory is divided into different segments and needs a qualifier to identify
each segment
- in a flat memory model the programmer doesnt need to switch for data and code
9. what is paging, segmentation y do we need it?
Paging
- Paging is a techinque where in the OS makes available the data required as quickly as possible. It stores
some pages from the aux device to main memory and when a prog needs a page that is not on the main
memory it fetches it from aux memory and replaces it in main memory. It uses specialised algorithms to
choose which page to replace from in main memory.
Caching
- It deals with a concept where the data is temperorarily stored in a high speed memory for faster
access. This data is duplicated in cache and the original data is stored in some aux memory. This
concepts brings the average access time lower.
Segmentation
- Segmentation is a memory management scheme. This is the technique used for memory protection.
Any accesses outside premitted area would result in segmentation fault.
Virtual Memory
- This technique enables non-contiguous memory to be accessed as if it were contiguous. Same as
paging.

10. write a code to check whether a stack grows upwards or downwards?
void checkStack()
{
int i=2;
int j=3;
if(&i > &j) printf("stack grown downwards");
else printf("stack grows upwards");
}
11. why do we require semaphore?
For process synchronization, it is a mechanism to invoke the sleeping process to become ready for
execution. Its mechanism where a process can wait for resources to be available.typical example is
producer consumer process. The producer process creates resources and signals the semaphore saying
resource is available. Consumer process waiting on the semaphore gets the signal that resource is
available.
12. write a small piece of code protecting a shared memory variable with a semaphore?
int global_i;
void increment_shared_memory {
wait(semaphore);
global_i++;
signal(semaphore);
}
13. what are the different types of semaphores and where they are used?
Binary semaphore and counting semaphore. Binary semaphore is same as mutex. Binary semaphore
tries to protect only one resource.
Counting semaphore is used in case of multiple resource. For ex: we have 4 printers then the counting
semaphore value will be init to 4. When it reaches 0, the task waiting on the semaphore is suspended.
14. what are the different inter process communications?

semaphore, mutex, message passing, shared memory, socket connections
15. what is present in .bss
- The bss section contains uninitialized data, and is allocated at run-time. Until it is written to, it remains
zeroed
16. what are the different segments of a program (code, data,stack,heap etc)
Object file or memory Segments:
Code segment
- This phrase used to refer to a portion of memory or of an object file that contains executable computer
instructions. It is generally read-only segment.
data segment
- This is one of the sections of a program in an object file or in memory, which contains the global
variables that are initialized by the programmer. It has a fixed size, since all of the data in this section is
set by the programmer before the program is loaded. However, it is not read-only, since the values of
the variables can be altered at runtime.
.bss
This segment of memory is part of data segment that contains uninitialized data (static variables). These
are initialized to 0 and later assigned values during runtime.
stack segment
- This segment of memory is a special stack which stores information about the active subroutines of a
task. It contains the return address to be branched to after a sub-routine has finished execution. It
contains local variables of the sub-routines and the parameters that are passed to those sub-routines.
heap segment
- The segment of memory which is used for dynamic memory allocation is known as heap. It is the
responsibility of the programmer to deallocate it after its use. Or alternatively it will be garbage
collected by the OS.
17. what is an ELF
- Executable and Linking Format is a common standard file format for executables, object code, shared
libraries, and core dumps.
18. what is priority inversion?
- In a scenario where a low priority task holds a shared resource (example semaphore) that is required
by a high priority task. This causes the execution of the high priority task to be blocked until the low
priority task has released the resource. This scenario is averted by the OS by increasing the priority of
the low-proi process until it completes the task and releases the resources.

Mutex:
Is a key to a toilet. One person can have the key - occupy the toilet - at the time. When finished, the
person gives (frees) the key to the next person in the queue.
Officially: "Mutexes are typically used to serialise access to a section of re-entrant code that cannot be
executed concurrently by more than one thread. A mutex object only allows one thread into a
controlled section, forcing other threads which attempt to gain access to that section to wait until the
first thread has exited from that section."
Ref: Symbian Developer Library
(A mutex is really a semaphore with value 1.)
Semaphore:
Is the number of free identical toilet keys. Example, say we have four toilets with identical locks and
keys. The semaphore count - the count of keys - is set to 4 at beginning (all four toilets are free), then
the count value is decremented as people are coming in. If all toilets are full, ie. there are no free keys
left, the semaphore count is 0. Now, when eq. one person leaves the toilet, semaphore is increased to 1
(one free key), and given to the next person in the queue.
Officially: "A semaphore restricts the number of simultaneous users of a shared resource up to a
maximum number. Threads can request access to the resource (decrementing the semaphore), and can
signal that they have finished using the resource (incrementing the semaphore)."
Ref: Symbian Developer Library
Difference between mutex and binary semaphore
1. The ownership of a mutex is with the single thread, meaning the same thread which has acquire the
lock can only release it.
whereas in semaphore any other thread or process can release the semaphore taken by a
process/thread
2. If a process locking the semaphore is killed by any chance and another process waiting for the lock to
be released, never gets notified.
Whereas in mutex, if another process is waiting for the lock, and the process acquired mutex got killed,
the kernel informs
3. recursion is not possible with semaphore, meaning locking the same semaphore again by the same
process will lead to deadlock condition.
but mutex recursion can be enabled. By which the same process can acquire the mutex lock any number
of times
4.semaphore doesnt support priority inheritance, so shouldn't be preferred for RTOS
Goood example of semaphore
Operating System Questions & Answers – RTOS

This set of Operating System Multiple Choice Questions & Answers (MCQs) focuses on “RTOS”.
1. In real time operating system
a) all processes have the same priority
b) a task must be serviced by its deadline period
c) process scheduling can be done only once
d) kernel is not required
View Answer
Answer: b
Explanation: None.
2. Hard real time operating system has ___ jitter than a soft real time operating system.
a) less
b) more
c) equal
d) none of the mentioned
View Answer
Answer: a
Explanation: Jitter is the undesired deviation from the true periodicity.
3. For real time operating systems, interrupt latency should be
a) minimal
b) maximum
c) zero
d) dependent on the scheduling
View Answer
Answer: a
Explanation: Interrupt latency is the time duration between the generation of interrupt and execution of
its service.
4. In rate monotonic scheduling
a) shorter duration job has higher priority
b) longer duration job has higher priority
c) priority does not depend on the duration of the job
View Answer
Answer: a
Explanation: None.
5. In which scheduling certain amount of CPU time is allocated to each process?
a) earliest deadline first scheduling
b) proportional share scheduling
c) equal share scheduling
View Answer
Answer: b
Explanation: None.

6. The problem of priority inversion can be solved by
a) priority inheritance protocol
b) priority inversion protocol
c) both priority inheritance and inversion protocol
View Answer
Answer: a
Explanation: None.
7. Time duration required for scheduling dispatcher to stop one process and start another is known as
a) process latency
b) dispatch latency
c) execution latency
d) interrupt latency
View Answer
Answer: b
Explanation: None.
8. Time required to synchronous switch from the context of one thread to the context of another thread
is called
a) threads fly-back time
b) jitter
c) context switch time
View Answer
Answer: c
Explanation: None.
9. Which one of the following is a real time operating system?
a) RTLinux
b) VxWorks
c) Windows CE
d) All of the mentioned
View Answer
Answer: d
Explanation: None.
10. VxWorks is centered around
a) wind microkernel
b) linux kernel
c) unix kernel
View Answer
Answer: a
Explanation: None.

For Automotive Protocols

CAN and LIN bus technology
Introduction:
 An Electronic Control Unit, simply called ECU, generally consists of microcontroller(s),
sensors, power switches, drivers and voltage regulator(s).
 Such a typical ECU is often used in the automotive domain.
 For a long time it was usual practice to connect the growing number of sensors and
actuators directly to a central ECU.
 Automotive applications contains many ECUs, these ECUs communicate through
different automotive bus protocols.CAN, LIN and FelxRays.
Network Characteristics:
1. Transmission Medium
 Single wire :Up to 50 Kb/s
 Two wires differential: Up to 125 Kb/s
 Two wires unshielded twisted: pair(UTP) Up to 500 Kb/s
 Two wires shielded twisted: pair(STP) Up to 10 Mb/s
 Optical fiber Up to 25 Mb/s
2. Line Coding:
 Return to Zero (RZ)
With RZ a '0' bit is represented by 0 volts whereas a '1' data bit is
represented by +V volts for half the cycle and 0 volts for the second
half of the cycle.
 Non returning to zero (NRZ)
NRZ encoding uses 0 volts for a data bit of '0' and a +V volts for a data
bit of '1'.
3. Data Packetization:
A packet is a basic unit of communication over a digital network.
A packet is also called a datagram, a segment, a block, a cell or a frame
Depending on the type of network.
Fram identification: massage id or destination id
4. Network Topology
 Ring topology
 Star topology
 Bus topology

5. Transmission Speed
 Transmission rate: is the theoretical rate at which user data can be
transmitted across a circuit.
 Bit rate: is the number of bits that pass a given point in a
telecommunication network in a given amount of time, usually a second.
 Baud rate: is the measurement of the number of times per second a
signal in a communications channel changes.
Communication Terminologies
1. Network Layers :TCP/IP Model
 Physical layer ( Driver) Performs the hardware access and details such as (electrical and
mechanical connections to the network, transmission of binary data as changing voltage
levels on wires or similar concepts on other connectors, and data rates) to the upper layer.
 Interface layer Provides the functional procedural means to transfer data between
network entities and might provide the means to detect and possibly correct errors that
may occur in the Physical Layer. Framing, Acknowledgment , Sequence Numbering,
Error Detection, Retransmission and Flow Control.
 Transportation layer: Responsible of segmentation and reassembly f the messages that
don’t fit in one Frame.
2. Synchronous/Asynchronous
 Synchronous transmissions: Synchronized by an external clock.The stream of data
to be transferred is encoded as fluctuating voltages on one wire, and a periodic
pulse of voltage is put on another wire (often called the "clock" or "strobe") that
tells the receiver "here's where one bit/byte ends and the next one begins".
 Asynchronous transmissions: Synchronized by special signals along the
transmission medium. There is only one wire/signal carrying the transmission. The
transmitter sends a stream of data and periodically inserts a certain signal element
into the stream which can be "seen" and distinguished by the receiver as a sync
signal.
Examples
1. SPI (Serial Peripheral Interface Bus) Full duplex
Master device initiates the data frame.
Multiple slave devices are allowed with individual slave select (chip select)
lines.

2. I2C (Inter-Integrated Circuit)
Half duplex
Multi Master
3. UART (Universal asynchronous receiver/transmitter ) Serial Communication
TxD and RxD signals used to transmit/receive data
Start, Stop and Parity bits used for signaling
3. Protocol Orientations
Message Orientation
 Message ID is used to identify the message
All receivers receive the message and only the receiver who
interested in it will perform processing
Destination orientation
 Destination ID is used to identify the message
The destination should be known before sending
Only one receiver receive the message.
LIN(Local Interconnect Network)
Why LIN?
 Low Cost (cost reduction)
 Single Wire
 Low Baud Rate
 Low Speed Application
 (speed up to 20 kbit/s)
 Self Synchronization Mechanism
 Easy Implementation
 Quality Enhancement
 Single Master
 LIN is the communication protocol for a low-speed network to which all comfort and
convenience applications in the car are connected.

 Instead of every air conditioning vent, electrical seat motor and sunroof being
individually wired point-to-point to its own switches, only one wire can connect up to 16
separate points using „LIN“.
 LIN can be used for every application which has no demand for high data rates.
What is LIN?
LIN (Local Interconnect Network) is a low cost serial communication system for distributed
electronic systems in vehicles. It complements the existing portfolio of automotive multiplex
networks. LIN enables cost-effective communication for smart sensors and actuators where the
bandwidth and versatility of CAN is not required.
The Key Features of LIN are:
 Low cost single-wire implementation
 Speed up to 20Kbit/s (limited for EMC reasons)
 Single Master/Multiple Slave Concept
 No arbitration required
 Low cost silicon implementation based on common UART/SCI interface hardware
 Self synchronization in the slave nodes without crystal or ceramics resonator
 Does LIN replace CAN?
No, LIN and CAN co exist in the automotive market.
LIN addresses an application space that requires less bandwidth and versatility when
compared to the CAN application space.
 What are the target applications for LIN Bus?
Target automotive applications include mirrors, window lift, doors switches, door lock,
HVAC motors, control panel, engine sensors, engine cooling fan, seat positioning motors,
seat switches, wiper control, light switches, interface switches to radio/navigation/phone,
rain sensor, light control, sun roof, RF receivers, body computer/smart junction box,
interior lighting and more.
 Can LIN be used for non-automotive applications?
Although designed for automotive applications, LIN is not limited to automotive
applications and has found it's way already into applications such as appliance and
consumer.

CAN(controller area network)
 CAN is a serial bus protocol to connect individual systems and sensors as an alternative
to conventional multi-wire looms. It allows automotive components to communicate on a
single or dual-wire networked data bus up to 1Mbps
 Most motor vehicle CAN networks operate at a bus speed of 250KB/s or 500KB/s,
although systems are available operating at up to 1MHz.
 Can used Arbitration : CAN uses the established method known as Carrier Sense,
Multiple Access with Collision Detect (CSMA/CD)
 Bit encoding: CAN uses Non Return to Zero (NRZ)
 Message Frames: In a CAN system, data is transmitted and received using Message
Frames. Message Frames carry data from a transmitting node to one, or more, receiving
nodes.
LIN CAN
Master Single master Multi master
Bit rate 1: 20 kb/s 1k: 1Mb/s
Configuration UART – SCI – Control Control
Message format 2,4,8 byte data
3 byte control
 Standard protocol
5 control
 Extended protocol
8 control
0-8 data for both

For Testing /Validation

Concepts:
 Software: is a computer program that runs on a processor with some associated
documents.
 process is a sequence of activities with which we are solving any problem that might
face us.
 system engineering VS software engineering
 system engineer :
• make a decision that this module is implemented with hardware and
another with software and so on and put the interfaces between them
• also the system engineer has his/her own modeling tools
define input , output and functionality and give them to the software engineer
 Software engineer:
• take one module form these modules assigned by the system engineer.
 HSI:Hardware Software Integration :
• document describe the interface between the software and hardware
and it comes after the system specifications of software and hardware.
 Process model :set of activities to reach the goal
 WaterFall Model: do requirement , design, implementation and unit test, integration all
as one shote
 Disadvantage of this model:
1. Rigid: Ya3ni law el requirements homma 50 7aga fa ana mottar enni astanna le7ad
makol el requirements tetgamma3 3andi…we beltali howa Rigid gedan. La2en el
change management hena sa3b gedan. Ya3ni dah yenfa3 le ay mashroo3 el
requirements beta3to ma3rofa we mo7adada we sa3b tetghayar. Ya3ni yenfa3
masalan le mashroo3 takharog.
Fa law el requirements etghayaret wana fel implementation aw zaad 3aleha 7aga
yeb2a ana mottar 2a3mel el system design we el detailed design men el awel we
gedeid.
2. Difficult to deliver prototype for a cutomer: lazem astna kolo 3lshan aslm 7aga
 Incremental V model: in the level of HLD there are small v models
o Less Rigidity than WaterFall Model and V-Model “ law feih increment el
requirement beta3etha mosh gahza asebha delwa2ty”
o Better Management : can work in many increments in parallel”
o Better Change Management “ any change in the requirements affects only the
increment of that concern”

Types of Documentation including:
1.Requirements - Statements that identify attributes capabilities, characteristics, or qualities of a
system. This is the foundation for what shall be or has been implemented.
2.Architecture/Design - Overview of software includes relations to an environment and
construction principles to be used in design of software components.
3.Technical - Documentation of code, algorithms, interfaces, and APIs.
4.End User - Manuals for the end-user, system administrators and support staff.
5.Marketing - How to market the product and analysis of the market demand.
For V model:
1. System requirement: what is the problem?
2. Design: How to solve the problem?
Any design should have design alternatives and choose one of them through selection
criteria.
3. Implementation: which is easiest one
4. Integration:
5. Validation: do the right system

Requirement Specification Methodologies:
1-functional methodologies(Data flow diagram)
 a functional requirement defines a function of a software system or its component.
 DFD illustrates this flow of information in a process based on the inputs and
outputs. A DFD can be referred to as a Process Model.
 Additionally, a DFD can be utilized to visualize data processing or a structured
design.
 A designer usually draws a context-level DFD showing the relationship between the
entities inside and outside of a system as one single step.
Level0: SCD system context diagram
 Determine the system boundary
Level 1: divide the system into components based on modes
 DFD and CFD: CFD is DFD and added events , control itms
 STD :state transition Diagram also in level 1 ..this is a control state machine of
Level 1
Level 2: state machine
Requirement management:
1. Requirement feasibility:
o Easiest way for feasibility: ask if there is system found like this or no
o Ask if the needed resources found for this project or not
o Cost
o Ask customer: why , how , when , what
2. Requirement Elicitation “formulate the need into requirements”
3. Requirement Interface Nature “Requirement Analysis”
 Requirement should be :
1. atomic : y3ny mtksra l as3’ar 7aga
2. Certain don't write statments which convey uncertainity
3. Testable “Measurable” like the availability of the device for example
4. Clear “Not ambiguous”
 process: A systematic series of actions directed to some end.
 Methodology: System of methods, principles, and rules for regulating a given discipline.

2.Non functional requirement(Quality of Service Design):
 Constrains on: size , jitter , ……etc
 To increase performance
 Anything not in: DFD, CFD
Testing
 Quality control: usually focuses on ensuring the requirements are being met, the overall
project is focused on the correct objectives, and risk is being managed.
 Quality Assurance: is focused on the day to day aspects of a project and is used to
determine if procedures are followed.
 Verification:
o Are we building the product right?
o Does the software conform to its specification?
o Includes reviews, inspections, walkthroughs, unit testing and integration testing.
o Main purpose is to detect defects in the artifacts of the system under development.
 Validation :
o Are we building the right product?
o Does the software meets the customer requirements?
o Includes program reviews, and acceptance testing
 Static verification:
Use sw inspection(checklist) and without execution
Inspection Roles:
 Author or owner: The programmer or designer responsible for producing the program or
document. Responsible for fixing defects discovered during the inspection process.
 Inspector: Finds errors.
 Scribe: Records the results of the inspection meeting.
 Chairman: Manages the process and facilitates the inspection. Reports process results to
the Chief moderator.
 Chief moderator: Responsible for inspection process improvements, checklist updating,
standards development etc.

Inspection checklist:
Data faults
 Are all program variables initialized before their values are used?
 Have all constants been named?
Control faults
 For each conditional statement, is the condition correct?
 If a break is required after each case in case statements, has it been included?
Input/output faults
Are all input/output variables used?
Interface faults
 Do all function and method calls have the correct number of parameters?
 Do formal and actual parameter types match?
 Are the parameters in the right order?
 Positive Testing is the process of executing a program or a system with the intent of
making sure that it does everything it is supposed to do.
 Negative Testing is the process of executing a program or a system with the intent of
making sure the system does not do anything it is not supposed to do.
 Test Case is a collection of input values (test data) and a collection of expected output
values designed to test a specific situation of a running software system or part of a
system.
Testing levels:
Unit testing: testing of individual components
 Use driver: to drive component  mn fo2
 Use stub: ti be derived component  mn t7t
Integration: testing collections of units integrated into sub – systems or major
component
Reasons why integration test is mandatory:
 Differences in the understanding of business requirements between multiple
developers
 Different interface assumptions; structures and ranges
 The modules still have errors that were not uncovered in unit testing

 Time spent on integration test is impacted by the clarity of the interfaces design
and the strength of the unit test
1. Big Bang Approach ties all of the system modules together at one shot.
Advantages:
 Suitable for small-sized and simple systems with limited number of components
 Saves the time of developing drivers and stubs
 Suitable when modules have been heavily unit tested
 Helps for showing the overall system behavior early
Disadvantages:
 Risky for systems with large number of components
 Complicates the debugging process
 Integration cannot start before all system modules are ready
2. Incremental Top-Down approach, the general modules at the top of the overall logic
path are tested first, using stubs for the called modules, then the called modules are
added using stubs for modules they might call.
Advantages: easier to logically understand and helps for seeing the big picture first.
Disadvantages: in most cases, it defers the bulk of the complex processing until later.
3. Incremental Bottom-Up approach, start off with modules at the lower level and use
driver programs to call them, then replace the drivers with the actual programs and
move up the program hierarchy until all the modules are in place.
Advantages: in most cases, it checks for the bulk of the complex processing at the beginning.
Disadvantages: harder to logically understand and harder to see the big picture until later.
System testing: testing the complete system prior to delivery
 Executing test cases on the entire system in the intention of finding defect
 Both verification and validation are applicable.
 Both functional and non-functional are applicable.
Acceptance testing: testing by users to check that the system satisfies requirements,
sometimes called alpha testing

 White – Box testing
o Testing the component based on its internal logical structure
o Uses the code paths and statements to generate Test Cases
o Ignores specifications
o Serves for verification only
o Applicable in unit-test only
 Black – Box testing
o Testing the UUT as a black box based on its outer most interfaces without
looking into the implementation details
o Uses the specifications to generate Test Cases
o Ignores code
o Serves for both verification and validation
o Applicable in all test levels
Test Case Components
1. Test Case ID: is the name that identifies the TC
2. Test Case Purpose
3. Environment Setup
o Platform initialization and configuration
o Tools preparation and configuration
o Media sniffers and analyzers preparation
4. Preconditions
o Precondition is a condition that needs to be satisfied before executing the Test
Case.
o Preconditions usually put the system in a state where its behavior is predictable.
5. Test Procedure:
o Actions
o Verification Points (Expectations)
6. Post-conditions: maybe expected output
 Non-functional test aims to measuring the system behavior and performance under loads
and variant conditions.
Performed using specialized tools, usually cannot be held by manual test.

Types of non functional test:
1. Performance Test: evaluate the SUT performance in terms of the following:
Speed, accuracy, resources Consumption
2. Load Test: loading the SUT gradually till the usage approaches the system’s
maximum capacity
3. Stress Test: loading the SUT rapidly till the usage goes beyond the system’s
maximum capacity in an attempt to break down the system
4. Reliability Test: test the stability of the SUT over long time of continuous operation
and under different conditions, “long time” differs from a system to another
5. Robustness Test: test the capability of the SUT to tolerate and over come invalid
inputs and conditions
6. Configuration Test: test the behavior of the SUT under different combinations of the
possible configurations
7. Usability Test: test how friendly the system is to new users, usually uses the Test-as-
you-go technique
Common Testing Terms:
 Monkey Test: unplanned testing, testing randomly without Test Cases
 Environmental Test: test tolerance for heat, motion, humidity, .etc
 Alpha Test: actual testing by potential user/customer at the development site
 Beta Test: actual testing by potential user/customer at the users’ site, the product is
released to a selected group of users
 Regression Test: verify that the updates in the SUT to fix a recently reported bug or to
integrate a new feature/component did not negatively impacted the already passing TCs

 A Bug is an error or flaw in a computer program that may prevent it from working
correctly or produce an incorrect or unintended result.
 A bug is said to be consistent if there is a fixed procedure that reproduces the bug every
time it is executed under the same conditions
 A bug is said to be inconsistent if the reproduction procedure does not show the bug
every time it is executed under the same conditions
 A Test Plan is a management planning document that shows:
o How the testing will be done
o Who will do it
o What will be tested
o How long it will take
o What the test coverage will be, i.e. what quality level is required
 Structure of a Test Plan
o Introduction: name of the project, brief description
o Test Scope: Features included and features not included
o Assumptions
o Test Strategy: Test Types, test Approaches, test Techniques
o Test Suite: Test objectives are created for each test group and subgroups
o Test Execution Strategy
o Test Team: its roles
o Test Effort Estimation:
1. Expected number of TCs for each feature
2. Resources and time needed to develop the test environment, if any
3. Resources and time needed to design and implement the TCs
4. Resources and time needed test execution activities; testing, retesting, bug
reporting.. etc

Thanks and Good Luck
Embedded System
Learn In Depth

Autosar Basics hand book_v1

Recommended

More Related Content

What's hot (20)

Similar to Autosar Basics hand book_v1 (20)

More from Keroles karam khalil (20)

Recently uploaded (20)

Autosar Basics hand book_v1