Autosarhandbookv1 190109141918

Download as pdf or txt
Download as pdf or txt
You are on page 1of 93

Follow us

AUTOSAR
Press
here
#LEARN_IN DEPTH

#Be_professional_in
embedded_system

Handbook

Prepared by: Eng.Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Follow us

Index
Press
here
#LEARN_IN DEPTH

#Be_professional_in
embedded_system

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

Study
(RTOS) Basics
Study
AUTOSAR OS
Which is based on
OSEK/VDX
Study
Study Automotive
protocols/Models
AUTOSAR Basics (CAN, TTCAN, CANFD, LIN
and FlexRay)

Solve Technical
Exams/interview questions

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Follow us

Automotive Press
here

embedded system
#LEARN_IN DEPTH

#Be_professional_in

(10 parts)
embedded_system

Step 1
Study the
following
You should Study well the Following parts: 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 3 (OSEK-VDX) PART 2
Automotive Embedded System Part 4 (OSEK-VDX) PART 3
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)

If you don’t have a time you just need to see the Step 2
Following C conclusion, if you already aware for validate you
them so you can skip the step 1. are aware for
Note: you will find the conclusion in this revision those
conclusion or
not
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
Follow us

Automotive Press
here

embedded system
#LEARN_IN DEPTH

#Be_professional_in
embedded_system

Step 3
Solve the C
Solve the Corner questions/tricks for all the Tricks/questions
covered C topics

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Embedded System
Learn In Depth

RTOS Conclusion

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Definitions Bare-Metal application

Bare metal C - Code


“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.

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.
• Windows IOT
• Linux Command
• Graphical GUI “ex.QT application”
• C/C++ app.

• RTOS Tasks

• Autosar SW Component OS
Application
Embedded windows

Embedded Linux
• Linux Kernel “Linux.org”
• Open embedded YOCTO
• Android OS
RTOS
• Free RTOS Autosar
• μC/OS-III
• RTOS OS + BSW +RTE

Drivers
Embedded Linux Drivers

RTOS Drivers

MCAl Layer

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
What is Real Time?
“not only depends upon the logical Real Time:
correctness of the computation but also
upon the time
produced.
at which the result is Correct logic
 If the timing constraints of the system
are not met, system failure is said
A real time system is one in which the
With a specific
correctness of the computations to have
occurred.” at specific timeline
Timeline
• Soft real time
Real Time System • Tasks are performed by the system as fast as
 A system is said to beReal Time if it is possible, but tasks don’t have to finish by
specific times
required to complete it’s work & deliver it’s
• Multitask based on Priority scheduling
serviceson time .
• Ex. Multimedia streaming
 Example – Flight Control System
25 frames per second on an average
 All tasks in that system must execute on
time.
• Hard real time
 Non Example – PC system • Tasks have to be performed correctly and on
time
 There are types of Real Time System • Multitask based on Deadline scheduling
Soft real time
Hard real time • 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 Task Task
1 0
•Less porting efforts
•Better reusability

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Characteristics of an RTOS Foreground/Background Systems
• Reliability:
• Available and doesn’t fail.
• An application consists of an
infinite loop that calls modules
• Predictability: (that is,
• Deterministic with small time variance.

• Performance:
functions) to perform the desired
• Fast enough.
operations (background).
• Compactness • Interrupt Service Routines (ISRs)
• Small and efficient. handle asynchronous
• Scalability events (foreground).
• Result of modularity and RTOS
configurations to be used in many So Foreground is also called
systems. interrupt level while background is
called task level
Background
Handling an Interrupt
ISR ISR
1. Normal ISR
program Foreground
(more
execution importa
nt)

2. Interrupt 3. Processor
occurs state saved
4. Interrupt routine runs

6. Processor state 5. Interrupt routine


restored terminates

7. Normal
program
execution
resumes

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Reentrancy  non-reentrant  reentrant
• A reentrant function is a version
function that can be used
by more than one task int temp; // global function swap (int *x, int *y) {
without cause of data int temp; // local
corruption.
function swap(int *x, int *y) {
• A reentrant function can be temp = *x;
interrupted at any time and
resumed at a later time temp = *x; *x = *y;
without loss of data. *x = *y; *y = temp;

• An error caused by a non- *y = temp; }


reentrant function may not }
show up in your application
during the testing phase

Non-
reentrant
function

Process or Task
• A task is usually implement in C by writing a function
Task 1 Task 2
• When a C function is executing, it is called a process or task
• So Task is not code int x;
• Two tasks can be executing the same code simultaneously

• When a process is created, it is allocated a number f int Func() {


resources by the OS, which may include: int y;
• –Process stack y = y + 1;
• –Memory address space x = x + 1;
• –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
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
Tasks conclusion
 Each task thinks it has the CPU to itself
Void task1()
 Each task has its own stack space and its own set {
of CPU registers
 Each task has a priority // a sequence of
 A task may well take the form of //initialisation code
a sequence of initialisation code; followed by
While(1)

 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:
//application code
 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

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

Task Delete Task Gets Event Task Pending Events

Task Create Highest Priority Task Interrupt


Dormant Ready Running ISR
Task Delete Task is Preempted Int. Exit

ENG. Keroles Shenouda Task Delete


https://www.facebook.com/groups/embedded.system.KS/
Scheduling - types
preemptive Non-preemptive
• 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-preemptive Low-priority Task


• It is also called cooperative multitasking;
• tasks cooperate with each other to share the CPU. ISR
• 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 ISR makes the
CPU. high-priority task ready
• asynchronous events are handled using interrupts
• tasks still have an assigned priority
advantages: High-priority Task
- interrupt latency time is low
- less need to “guard” shared resources
-At the task level, non-preemptive kernels can also low-priority task
use non-reentrant functions.
disadvantages: Relinquishes the CPU
- responsiveness is non-optimal & non-deterministic (low priority task is finished) Time
- one task may lock-up system

Preemptive
• the highest priority task (ready) is given control Low-priority Task
of the CPU
• current running task is suspended IS
R
• after an Interrupt Service Routine (ISR), the new High-priority Task
highest priority task is run
• Most commercial real-time kernels are ISR makes the
preemptive high-priority task ready
advantages:
- responsiveness is optimal & deterministic
(Execution of the highest-priority task is deterministic)
-Task-level response time is minimized
disadvantages:
high-priority task
- shared resources must be properly guarded
Relinquishes the CPU
-Should not use non-reentrant functions unless
exclusive access to these functions is ensured
ENG. Keroles Shenouda Time
https://www.facebook.com/groups/embedded.system.KS/
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.

1. First-Come First-Served
Scheduling Algorithms in 2. Shortest Job First
3. Round Robin
time-shared System 4. Round-robin with priority
scheduling

First In First Out Algorithm Shortest Job First Algorithm


• Also known as First Come, First Served • Also known as Shortest Job First (SJF).
(FCFS).
• With this strategy the scheduler arranges
• It is the simplest scheduling algorithm. processes with the least estimated
processing time remaining to be next in
• FIFO simply queues processes in the order the queue.
that they arrive in the ready queue
• If a shorter process arrives during another
• It is non-preemptive process 'execution, the currently running
process may be interrupted.
• scheduling overhead is minimal.
• This algorithm is designed for maximum
• Throughput can be low. throughput in most scenarios.
• This is considered as a very good algorithm • Starvation is possible, especially in a busy
when few small tasks all with small system with many small processes being
execution times run
• This algorithm can be
• Preemptive (Running task can be interrupted
by another task).
• Non Preemptive

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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

Round-robin with priority


scheduling
• 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.

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
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
Priority Inversions
• Low-priority process acquires
lock, blocks higher-priority
process
• Priority inheritance temporarily
raises process priority
• Difficult to analyze

Priority Inheritance Solution


 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 Task 1 (high)
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 2 (medium)
task 3.
 Task 1 releases the resource at point
5, but keeps running also task 2 is
ready, because it has the highest Task 3 (low)
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 1 2 3 4 5 6
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.

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Two shared Resource Control
the semaphore the mutex = MUTual
EXclusion.

Shared Resource
Resource
A shared resource is a
A resource is any entity used
resource that can be used by
by a task. A resource can thus
more than one task. Each task
be an I/O device such as a
should gain exclusive access
printer, a keyboard, a display,
to the shared resource to
etc. or a variable, a structure,
prevent data corruption. This
an array, etc.
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
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
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 Kindly Note: DPRAM test-and-set instructions can
common resource, they must first check a work in many ways
global variable When CPU 1 issues a test-and-set instruction, the
while it is being checked, and before it is DPRAM first makes an "internal note" of this by
set, by one task, it must be made storing the address of the memory location in a
inaccessible by the other special place. If at this point, CPU 2 happens to issue a
this can be achieved by: test-and-set instruction for the same memory
disabling interrupts (above) or location, the DPRAM first checks its "internal note",
some processors now support a recognizes the situation, and issues a BUSY interrupt,
single TAS instruction which tells CPU 2 that it must wait and retry.
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
semaphores
• a protocol mechanism to control
access to shared resources, signal 3. “my name is task 1”
the occurrence of an event or task 1 1. pend
allow two tasks to synchronize
• one analogy is that in order for a 4. post
task to use a resource it must first
draw a key for it Printer
• if the key(s) is in use, the task 2. pend
suspends
• wait on (pend) & signal (post) 6. post
semaphore task 2 5. “my name is
task 2”
• two types of semaphores:
• binary and counting (general)

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)

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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 2. Post 1. Pend
Task 2 Task 1
• 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

"bilateral rendezvous"
• bilateral rendezvous - two tasks can
be synchronized with each other by
using two separate semaphores

3. Signal Task 1 2. wait for signal from task 2

Task 2 Task 1

4. wait for signal from task 1 1. Signal Task 2

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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)

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Embedded System
Learn In Depth

AUTOSAR OS based on
OSEK-VDX Standard
Conclusion

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
Tasks in OSEK
• Tasks are « active » elements of the application
• 2 categories of tasks exist in OSEK/VDX:

Extended tasks
Basic tasks The task that are able to wait
A basic task is a sequential C for an event are called
code that must terminate Extended tasks

Tasks’ services Oil parameters

TASK(myTask)
{
//Task’s instructions

//Task_Service API
}

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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
NOTE:
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
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
Interrupts (ISR Management) in OSEK-VDX
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, ...)

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

Example on ISR2

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Counters and Alarms in OSEK-VDX
Goal:
perform an “action” after a number of “ticks” from an hardware device:

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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
shared resources in OSEK-VDX
STANDARD Resource
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 TASK myTask {
RESOURCE resA { PRIORITY = 2;
AUTOSTART = FALSE;
RESOURCEPROPERTY = ACTIVATION = 1;
STANDARD; SCHEDULE = NON;
RESOURCE = resA;
}; STACKSIZE = 32768;
};
“RES_SCHEDULER” 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.

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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().

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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;
Oil file
• able to call a subset of the operating system services.

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Embedded System
Learn In Depth

AUTOSAR Basics

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Automotive industry

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
AUTOSAR Process

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
AUTOSAR Basic Software Module (BSW)

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
CAN Communication Stack

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Diagnostic Communication Manager (DCM)

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
AUTOSAR Memory Stack

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
System Services on BSW

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
AUTOSAR
Benefits

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Classic Platform vs. Adaptive Platform

Adaptive AUTOSAR Use Cases

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
AUTOSAR System Design Process

SWC
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.
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
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
SWC elements
Ports
PPort  provide port
Rport  require port
PRPort  provide require port
Internal Behavior
Runnables
RTE Events
InterrunnableVaribales
Implementation (source or object code)

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
(Mapping SWC to OS tasks )

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
System modeling

You should
configure all
those modules,
but we just will
focus on the
AUTOSAR OS

Used BSW Modules

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
Embedded System
Learn In Depth

Automotive
Modules/Protocols

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Data Frame

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
FlexRay

• 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:

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
ENG. Keroles Shenouda
https://www.facebook.com/groups/embedded.system.KS/
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 - [email protected]
Sébastien Faucou - [email protected]
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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
Embedded System
Learn In Depth

RTOS Questions

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/
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 =
%s\n",uTest.age, uTest.height, uTest.name);
printf("sTest.age = %d , sTest.height = %f , sTest.name =
%s\n",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 :%d\n",x);
x = (x<<x<<x) | (x<<x<<x) | x<<!!x | !!x ;
printf("X After :%d\n",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
d) none of the mentioned
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
d) none of the mentioned
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
d) none of the mentioned
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
d) none of the mentioned
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
d) none of the mentioned
View Answer

Answer: a
Explanation: None.
Kindly you can find the Following Useful Embedded materials
For Automotive Protocols
On the internet (not prepared by me)
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  Standard protocol
3 byte control 5 control
 Extended protocol
8 control
0-8 data for both
Kindly you can find the Following Useful Embedded materials
For Testing /Validation
On the internet (not prepared by me)
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
Embedded System
Learn In Depth

Thanks and Good Luck

ENG. Keroles Shenouda


https://www.facebook.com/groups/embedded.system.KS/

You might also like