1

Unit IIISoftware Design & Testing Methods

Prof. R.K. Samaiya

2

What Is Embedded Software?

• Embedded software is a type of software that is built into hardware systems.

• This software is typically designed to perform one specific function, although a single piece of hardware may contain multiple pieces of software embedded in it.

• Any device that has circuit boards and computer chips have embedded software within it. Examples : Digital clocks, Cell phones, Calculators.

3

Types of Software

Software

System software

Utility software

Application software

4

System software

• It is the software used to manage and control the hardware components.

• It allow interaction between the hardware and the other types of software.

• Examples: o Operating systemo Device drivers

5

Utility software

• These software helps to maintain and protect the computer system but does not directly interface with the hardware.

• Examples:o Anti-virus softwareo Firewallso Disk defragmenters

6

Application software / apps

• These are designed to allow the to perform a specific task or set of tasks.

• Examples:– Web browsers– Office software– Games– Media Player

7

Algorithms

• Algorithms describes the general actions to be taken.• These are independent of programming language.• These are first step in the design of a program.

8

Steps in development of Algorithms

Problem definition

Development of a model

Specification of Algorithm

Designing an Algorithm

Checking the correctness of

Algorithm

Analysis of Algorithm

Implementation of Algorithm Program testing Documentation

Preparation

9

Software Development Models

• Development models are the various processes or methodologies that are being selected for the development of the project depending on the project’s aims and goals.

• There are many development life cycle models that have been developed in order to achieve different required objectives.

• The models specify the various stages of the process and the order in which they are carried out.

10

• The selection of model has very high impact on the testing that is carried out.

• The selected model will define the what, where and when to perform testing.

• Choosing right model for developing of the software product or application is very important.

• Based on the model the development and testing processes are carried out.

11

Software Development Models

SDLC Models

Waterfall model

V model

Incremental model

Agile model

Iterative model

Prototype Model

Spiral modelSDLC: software development life cycle

12

Waterfall model

http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm

13

Waterfall model phases

• In "Waterfall" approach, the whole process of software development is divided into separate phases. Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance

14

• It is a Linear-sequential life cycle model. This means that any phase in the development process begins only if the previous phase is complete.

• The outcome of one phase acts as the input for the next phase sequentially.

15

Waterfall model phases

Requirement Gathering and analysis: o Started with problem description in human language.o All possible requirements of the system to be developed

are captured in this phase and documented in a requirement specification doc.

o Concept is modelled in mathematical form or algorithms.o In embedded domain, software is associated with different

hardware units. Interaction & interfaces between software and hardware must be included during analysis.

16

System Design: o The requirement specifications from first phase are studied

in this phase and system design is prepared.o System Design helps in specifying hardware and system

requirements and also helps in defining overall system architecture.

17

Waterfall model phases

Implementation:o With inputs from system design, the system is first

developed in small programs called units, which are integrated in the next phase.

o Unit Testing : Each unit is developed and tested for its functionality which is referred to as Unit Testing.

Integration and Testing:o All the units developed in the implementation phase are

integrated into a system after testing of each unit. o Post integration the entire system is tested for any faults

and failures.

18

Waterfall model phases

Deployment of system:o Once the functional and non functional testing is done,

the product is deployed in the customer environment or released into the market.

Maintenance: o There are some issues which come up in the client

environment. To fix those issues patches are released.o Also to enhance the product some better versions are

released. Maintenance is done to deliver these changes in the customer environment.

19

Waterfall model phases

• All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases.

• The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model".

20

Waterfall Model Application

• Some situations where the use of Waterfall model is most appropriate are:– Requirements are very well documented, clear and

fixed.– Product definition is stable.– Technology is understood and is not dynamic.– There are no ambiguous requirements.– Ample resources with required expertise are available

to support the product.– The project is short.

21

Advantage

• The advantage of waterfall development is that it allows for departmentalization and control.

• A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

• Each phase of development proceeds in strict order.

22

Disadvantage• Inflexible partitioning of the project into distinct

stages• It does not allow for much reflection or revision. • This makes it difficult to respond to changing

customer requirements.• Once an application is in the testing stage, it is very

difficult to go back and change something that was not well-documented or included in the concept stage.

• Little opportunity for customer to preview the system.

23

V- model

• V- model means Verification and Validation model. • Just like the waterfall model, the V-Shaped life cycle

is a sequential path of execution of processes. • Each phase must be completed before the next

phase begins. Testing of the product is planned in parallel with a corresponding phase of development.

24

V- model

25

The various phases of the V-model

• Requirements like BRS and SRS begin the life cycle model just like the waterfall model. But, in this model before development is started, a system test plan is created.

• The high-level design (HLD) phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.

• The low-level design (LLD) phase is where the actual software components are designed. It defines the actual logic for each and every component of the system. Component tests are created in this phase as well.

26

• The implementation (Coding) phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

• Code: This is at the bottom of the V-Shape model. Module design is converted into code by developers.

27

Advantages of V-model

• Simple and easy to use.• Testing activities like planning, test designing

happens well before coding. This saves a lot of time.

• Higher chance of success over the waterfall model.

28

Disadvantages of V-model

• Very rigid and least flexible.• Software is developed during the implementation

phase, so no early prototypes of the software are produced.

• If any changes happen in midway, then the test documents along with requirement documents has to be updated.

29

When to use the V-model

• The V-shaped model should be used for small to medium sized projects where requirements are clearly defined and fixed.

• The V-Shaped model should be chosen when ample technical resources are available with needed technical expertise.

• High confidence of customer is required for choosing the V-Shaped model approach. Since, no prototypes are produced, there is a very high risk involved in meeting customer expectations.

30

Incremental Life cycle model • In incremental model the whole requirement is divided into various

builds. • Multiple development cycles take place here, making the life cycle a

“multi-waterfall” cycle. • Cycles are divided up into smaller, more easily managed modules.

Each module passes through the requirements, design, implementation and testing phases.

• A working version of software is produced during the first module, so we have working software early on during the software life cycle.

• Each subsequent release of the module adds function to the previous release. The process continues till the complete system is achieved.

31

• In the diagram above when we work incrementally we are adding piece by piece but expect that each piece is fully finished. Thus keep on adding the pieces until it’s complete.

• As in the image above a person has thought of the application. Then he started building it and in the first iteration the first module of the application or product is totally ready and can be demoed to the customers. Likewise in the second iteration the other module is ready and integrated with the first module. Similarly, in the third iteration the whole product is ready and integrated. Hence, the product got ready step by step.

32

Incremental Life cycle model

33

Advantages of Incremental model

• Generates working software quickly and early during the software life cycle.

• This model is more flexible – less costly to change scope and requirements.

• It is easier to test and debug during a smaller iteration.

• In this model customer can respond to each built.

• Lower risk of overall project failure

34

Disadvantages of Incremental model

• Needs good planning and design.• Needs a clear and complete definition of the

whole system before it can be broken down and built incrementally.

• Total cost is higher than waterfall.

35

When to use the Incremental model

• This model can be used when the requirements of the complete system are clearly defined and understood.

• Major requirements must be defined; however, some details can evolve with time.

• There is a need to get a product to the market early.

• A new technology is being used• Resources with needed skill set are not available

36

Prototyping Model

• The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements.

• This prototype is developed based on the currently known requirements.

• By using this prototype, the client can get an “actual feel” of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system.

37

• Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements.

• The prototype are usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality.

38

Prototyping Model

39

Advantages of Prototype model

• Users are actively involved in the development• Since in this methodology a working model of the

system is provided, the users get a better understanding of the system being developed.

• Errors can be detected much earlier.• Quicker user feedback is available leading to better

solutions.• Missing functionality can be identified easily

40

Disadvantages of Prototype model

• Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.

• Incomplete application may cause application not to be used as the full system was designed incomplete or adequate problem analysis.

41

When to use Prototype model

• Prototype model should be used when the desired system needs to have a lot of interaction with the end users.

• Typically, online systems, web interfaces have a very high amount of interaction with end users, are best suited for Prototype model.

• They are excellent for designing good human computer interface systems.

42

Spiral model• The spiral model is similar to the incremental model, with more

emphasis placed on risk analysis. • The spiral model has four phases: Planning, Risk Analysis,

Engineering and Evaluation. • A software project repeatedly passes through these phases in

iterations (called Spirals in this model). • The baseline spiral starting in the planning phase, requirements

are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

43

• Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’ (‘Business Requirement Specifications’) and ‘SRS’ (‘System Requirement specifications’).

• Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. If any risk is found during the risk analysis then alternate solutions are suggested and implemented.

• Engineering Phase: In this phase software is developed, along with testing at the end of the phase. Hence in this phase the development and testing is done.

• Evaluation phase: This phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

44

Spiral Model

45

Advantages of Spiral model• High amount of risk analysis hence, avoidance of Risk

is enhanced.• Good for large and mission-critical projects.• Strong approval and documentation control.• Additional Functionality can be added at a later date.• Software is produced early in the software life cycle.

46

Disadvantages of Spiral model

• Can be a costly model to use.• Risk analysis requires highly specific expertise.• Project’s success is highly dependent on the

risk analysis phase.• Doesn’t work well for smaller projects.

47

When to use Spiral model

• When costs and risk evaluation is important• For medium to high-risk projects• Users are not sure of their needs• Requirements are complex• New product line• Significant changes are expected (research

and exploration)

48

Measurement & Metrics

49

Need of Measurement

• Software is measured to:– Establish the quality of the current product or process.– To predict future qualities of the product or process.– To improve the quality of a product or process.– To determine the state of the project in relation to

budget and schedule.

50

Measurement & Metrics

• A measurement is an indication of the size, quantity, amount or dimension of a particular attribute of a product or process. – For example the number of errors in a system is a

measurement• A Metric is a measurement of the degree that

any attribute belongs to a system, product or process.

51

Metrics to quantify software development

MetricType & orientation of Metric

Technical Quality Productivity Human InterfaceCorrectness Y Y N NReliability Y Y N NEfficiency Y N N N

Maintainability Y N Y NFlexibility Y N Y YTestability Y Y Y NPortability Y N Y N

Reuse Y Y Y NUtility N Y N Y

Size N N Y N

Y- Applicable N- Not applicable

52

• Software measurement gives rise to software metrics.

Software metric

Product metric

Process metric

Project metric

53

• Product metrics describe the characteristics of the product such as size, complexity, design features, performance, and quality level.

• Process metrics can be used to improve software development and maintenance.– Examples include the effectiveness of defect removal

during development, the pattern of testing defect arrival, and the response time of the fix process.

• Project metrics describe the project characteristics and execution. – Examples include the number of software developers, the

staffing pattern over the life cycle of the software, cost, schedule and productivity.

• Some metrics belong to multiple categories. For example, the in-process quality metrics of a project are both process metrics and project metrics.

54

Software quality metrics

• Software quality metrics is “A measure of some property of a piece of software or its specifications”.

• Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process, and project.

55

• Software quality is divided into 2 levels: – Intrinsic product quality metrics– customer satisfaction metrics

56

Intrinsic product quality

• Intrinsic product quality is usually measured by the number of “bugs” (functional defects) in the software or by how long the software can run before encountering a “crash.”

57

Customer Satisfaction Metrics

• Customer satisfaction is often measured by customer survey data via the five-point scale:– Very satisfied– Satisfied– Neutral– Dissatisfied– Very dissatisfied.

• Satisfaction with the overall quality of the product and its specific dimensions is usually obtained through various methods of customer surveys.

Mars Climate Orbiter• The Mars Climate Orbiter / Mars Surveyor '98 Orbiter was a

robotic space probe launched by NASA on December 11, 1998 to study the Martian climate, atmosphere, and surface changes.

• On September 23, 1999, communication with the spacecraft was lost as the spacecraft went into orbital insertion, due to ground-based computer software which produced output in non-SI units of pound-seconds (lbf×s) instead of the metric units of newton-seconds (N×s) specified in the contract between NASA and Lockheed.

• The spacecraft encountered Mars on a trajectory that brought it too close to the planet, causing it to pass through the upper atmosphere and disintegrate.

• The primary cause of this discrepancy was that one piece of ground software supplied by Lockheed Martin produced results in a United States customary unit ("American"), contrary to its Software Interface Specification (SIS), while a second system, supplied by NASA, that used those results expected them to be in metric units, in accord with the SIS.

• The discrepancy between calculated and measured position, resulting in the discrepancy between desired and actual orbit insertion altitude

Ariane 5 (1996 explosion)• Ariane 5’s Purpose: delivering satellite to space• Control system of Ariane 5 composed of:– An inertial reference system (SRI)– An On-Board Computer (OBC)

• Rocket exploded around 40 seconds after lift-off.• Failure due to SRI software exception• Exception caused due to a data conversion

Issues

• For developing a safe and reliable system, types of faults and failures must be identified and how they can occurs.

• Software doesn’t conform to conventional or natural boundaries of stability, it can jump from zero to infinity in single step.

• Failures may have multiple sources.• Safety and reliability are system concerns, not

concern of software alone.

Development Plan

• Software faults affect safety , fault tolerance and reliability of the system and product.

• Careful plan reduces the risk from software failure.

• A plan for software should specify how to handle requirements, design, development, reviews, tests and documentation.

• Certain inputs shape the requirements like product goals, market constraints, prototype results hazard or risk analysis.

• A good development plan should:– Identify the risk– Set priorities for criticality– Prepare management and resolution strategies– Monitor the risk during development

Guidelines for Development plan of software

• Keep the program size as small as possible.• Keep the design of program as simple as

possible.• Reduce the development time beyond the

specified limits.• Keep team size as small as possible.• High efficiency software tools, methods &

techniques should be used

Safety & Reliability

• Efficient techniques & methods can produce safe & reliable software.– Develop a complete plan– Select safety and reliability requirements

according to the application.– Identify bugs & errors– Identify the method to remove bugs & errors

• 3 ways to improve reliability: – Describe in mathematical form or logical terms.– Systematic Management– Limiting software role

Guidelines for reliable software development– Make each module independent– Reduce the complexity of each task– Isolate task from external influence, both hardware and

timing– Proper communication should be present between tasks

Fault tolerance• It defines how a system prevents or respond

to bugs, errors, faults or failure.• Software are discrete, non linear systems. A

single operation can drastically change output.• Failure of Safety-critical systems can lead to

equipment damage, environmental harm, injury or death.

• Safety-critical systems requires Fail-safe mechanism.

• Fail-safe mechanism include:– Detection and correction of faults– Fallback modes that limits equipment function– Proper notification of faultsExamples:

• Cyclic redundancy checks on data communication • Watchdog timer

Watchdog timer

• Watchdog timer is a hardware that monitors a system characteristic to check the control flow.

• If it detects any fault it generates a logic pulse and inform the processor.

• Example: Suppose software is programmed to reset the count after a particular interval of time. Watchdog timer wait for a time interval and after this generate the logic pulse that indicates a fault, that software has hang up in a particular operation.

Faults in embedded software

• Sensor may produce signal exceed the specified limits or too large.

• Operator entered an Alphabetic character instead of number

• Once a system detects fault it must respond appropriately. – Real time systems can use roll back recovery (reconstructing

previous state) or roll forward recovery.System having watchdog timers may use either roll back recovery, roll forward recovery or both to respond to a detected fault.

71

Software bug• It is an error, flaw, failure or fault in a computer program or

system. • It produce an incorrect or unexpected result• Bugs arise from mistakes and errors made by people in either

a program's source code or its design, or in frameworks and operating systems used by such programs and a few are caused by compilers producing incorrect code.

• A program that contains a large number of bugs is called buggy.

• Reports detailing bugs in a program are commonly known as bug reports, defect reports, fault reports.

• Bugs can be generated because of– Incorrect conceptual design– Incorrect assumptions

Phases of Bug IntroductionBug can enters in software in any of 4 stages: 1. Intent or (during requirement phase)2. Translation3. Execution4. Operation

IntentS.N. Types Comments

1 Wrong Assumptions or misunderstanding

Insufficient grasp of the problem

2 Problem definition Correctly solving the wrong problem

3 Sizing Limits on operation too broadly or too narrowly

TranslationS.N. Types

1 Incorrect algorithm

2 Incorrect Analysis

3 Misinterpretation

ExecutionS.N Types Comments

1 Semantic error

Failure to understand how command works

2 Syntax error

Failure to follow-• Rules of language• Terminate statement• Terminate procedure

3 Logic error Wrong decision, branch to wrong label, improper initialization or termination of loop

4 Range error

Failure to predict the possible calculation, incorrect approximation

Execution

S.N Types Comments

5 Truncation error Incorrect rounding of calculation

6 Data error • Failure to predict the possible range of data or data types

• Not initializing or setting size of array

7 Misuse of language • Coding operation inefficiently or incorrectly

8 Documentation • Wrong or mismatching comments

Operation

S.N Types Comments

1 Changing paradigm

System operating in an unanticipated environment

2 Interface error Incorrect type or range of input and output

3 Performance Inadequate hardware resource or software timing

4 Hardware failure

Failure or incorrect functioning of subsystem

5 Human error

Debugging

• Embedded devices must run for months without crashing, within strict memory and processing limits and can have real-world interactions.

• Software debugging is one of the major tasks of programming.

• When the results of a program are examined, errors may be found through the discovery of their effects.

Hardware for embedded software debugging• Logic analyzer• Oscilloscope• In-circuit emulator (ICE) :

It is a hardware interface that allows a programmer to change or debug the software in an embedded system. The ICE is temporarily installed between the embedded system and an external terminal or personal

In-circuit emulator (ICE)

Debugger

“A software tool that is used to detect the source of program or script errors, by performing step-by-step execution of application code and viewing the content of code variables.”

• Debugging is the activity of finding the causes that produced undesirable program effects.

Debugging technique

Tracer Controlled Execution

Tracing Technique

Procedure for tracing technique:1. Run program2. Save states of the program3. Find cause of program's malfunction ( bug)

Controlled Execution

Procedure for tracing technique-1. Pause program execution at breakpoints.2. At breakpoint, study the state of the program. 3. Faulty program is executed and debugged through

many cycles until the fault is localized and fixed.

• Once errors are identified in a software system, to debug the problem, steps are

• Defect confirmation/identification: A problem is identified in a system and a defect report is created. A software engineer maintains and analyzes this error report and finds solutions to the following questions.– Does a defect exist in the system?– Can the defect be reproduced?– What is the expected/desired behavior of the

system?– What is the actual behavior?

Guidelines for debugging

• Individuals involved in debugging should understand all the causes of an error before starting with debugging.

• No experimentation should be done while performing debugging. The experimental changes instead of removing errors often increase the problem by adding new errors in it.

• When there is an error in one segment of a program, there is a high possibility that some other errors also exist in the program.

• It should be ensured that the new code added in a program to fix errors is correct and is not introducing any new error in it.

87

Check list for code inspection

88

Check list for code inspection

89

Style guidelines

The user interface

• User interface is the front-end application view to which user interacts in order to use the software.• User can manipulate and control the software as

well as hardware by means of user interface. • User interface is present at almost every place

where digital technology exists.–Examples computers, mobile phones, cars, music

players etc.

The user interface

• System users often judge a system by its interface rather than its functionality

• A poorly designed interface can cause a user to make errors and serious issues.

• Poor user interface design is the reason why so many software systems are never used

UI design

The UI design process

• UI design is an iterative process involving interaction between users and designers.

• The 3 core activities in this process are:– User analysis: Understand what the users will

do with the system– System prototyping: Develop a series of

prototypes for experiment– Interface evaluation: Evaluate these prototypes

with users.

UI design principles

• UI design must take account of the needs, experience and capabilities of the system users.

• Designers should be aware of people’s physical and mental limitations (e.g. limited short-term memory) and should recognise that people make mistakes.

User Interface Design Principles

Principle Description

User familiarityUse terms and concepts familiar to the user.

ConsistencyComparable operations should be activated in the same way. Commands and menus should have the same format, etc.

Minimal surpriseIf a command operates in a known way, the user should be able to predict the operation of comparable commands.

FeedbackProvide the user with visual and auditory feedback, maintaining two-way communication.

Principle Description

Memory loadReduce the amount of information that must be remembered between actions. Minimize the memory load.

Efficiency Seek efficiency in dialogue, motion and thought. Minimize keystrokes and mouse movements.

RecoverabilityAllow users to recover from their errors. Include undo facilities, confirmation of destructive actions, 'soft' deletes, etc.

User guidance Incorporate some form of context-sensitive user guidance and assistance.

Advantages of UI• They are easy to learn and use.

– Users without experience can learn to use the system quickly.

• The user may switch attention between tasks and applications.

• Fast, full-screen interaction is possible with immediate access to the entire screen

Problems• A GUI is not automatically a good interface

– Many software systems are never used due to poor UI design– A poorly designed UI can cause a user to make catastrophic errors

98

RTOS

Kernel• Kernel is a computer program that manages

I/O(input/output) requests from software and translates them into data processing instructions for the CPU.

• A kernel connects the application software to the hardware of a computer.

• Its main task are:– Executing processes– Handling interrupts

• real-time task scheduling algorithms based on how the scheduling points are defined.

• The three main types of schedulers according to this classification scheme are: – Clock-driven– Event-driven– Hybrid.

Real-time task scheduling

Real-time task scheduling algorithms based on how the scheduling points are defined.1. Clock Driven – Table-driven – Cyclic

2. Event Driven – Simple priority-based – Rate Monotonic Analysis (RMA) – Earliest Deadline First (EDF)

3. Hybrid – Round-robin

• The clock-driven schedulers are those in which the scheduling points are determined by the interrupts received from a clock.

• In the event-driven ones, the scheduling points are defined by certain events which precludes clock interrupts.

• The hybrid ones use both clock interrupts as well as event occurrences to define their scheduling points.

103

Clock-driven schedulers

• The clock-driven schedulers are those in which the scheduling points are determined by the interrupts received from a clock.

• Advantages: – Simple to write, debug & analyze.– Good for high speed data channels.

• Disadvantages: – Fails to handle burst of events.– Require more CPU cycle

Table-driven schedulers• Table-driven schedulers usually pre-compute

which task would run when, and store this schedule in a table at the time the system is designed or configured.

An Example of a Table-Driven Schedule

Cyclic schedulers

• Cyclic schedulers are very popular and are being extensively used in the industry.

• A large majority of all small embedded applications being manufactured presently are based on cyclic schedulers.

• Cyclic schedulers are simple, efficient, and are easy to program.

Cyclic schedulers

Example : Temperature controller.A temperature controller periodically samples the temperature of a room and maintains it at a preset value. Such temperature controllers are embedded in typical computer-controlled air conditioners.

Event Driven Schedulers

• In the event-driven schedulers, the scheduling points are defined by certain events which precludes clock interrupts.

• It uses event interrupt to control program flow. • It services interrupts by context switching or saving

CPU register states. • Context switching– Context switch is the process of storing and restoring the

state of a process or thread so that execution can be resumed from the same point at a later time.

• Types of Event Driven Schedulers – Simple priority-based – Earliest Deadline First (EDF) – Rate Monotonic Analysis (RMA)– Deadline Monotonic Algorithm (DMA)

Earliest Deadline First (EDF)

• In Earliest Deadline First (EDF) scheduling, at every scheduling point the task having the shortest deadline is taken up for scheduling.

Rate Monotonic Algorithm(RMA)

• This is a static priority algorithm and is extensively used in practical applications.

• RMA assigns priorities to tasks based on their rates of occurrence. The lower the occurrence rate of a task, the lower is the priority assigned to it.

• A task having the highest occurrence rate (lowest period) is accorded the highest priority.

Priority assignment to the task in RMA

Priority assignment to the task in RMA

Deadline Monotonic Algorithm (DMA)

• DMA is essentially a variant of RMA.• It assigns priorities to tasks based on their

deadlines, rather than assigning priorities based on task periods as done in RMA.

• DMA assigns higher priorities to tasks with shorter deadlines.