Roteiro

Teste de Software Embarcado Por que teste integrado de HW e SW?

Desafios para o teste de sistemas integrados
Processo de teste de software embarcado
Érika Cota - 2009
Técnicas de teste mais comuns
Proposta local

Sistemas Embarcados Sistemas Integrados de HW e SW

Sistemas eletrônicos com restrições de Problemas de confiabilidade devido ao hardware
hardware Software mais complexo => mais sujeito a falhas
memória Hardware e software co-dependentes
desempenho Níveis de qualidade e confiabilidade cada vez mais altos
potência
confiabilidade

onde o software tem papel fundamental na

operação e interage fortemente com o Teste (integrado) do sistema é fundamental
hardware
Projeto e Produção de um Sistema Embarcado Projeto e Produção de um Sistema Embarcado

Análise de Requisitos Análise de Requisitos

Projeto do Sistema (Análise) Projeto do Sistema (Análise)
Projeto da Arquitetura do Sistema Projeto da Arquitetura do Sistema
Projeto dos Módulos Projeto dos Módulos
Partição Hardware/Software Partição Hardware/Software
Planejamento do Teste
Programação Programação
Teste unitário Síntese e Verificação Teste unitário Síntese e Verificação
Teste integração SW-SW Fabricação Teste integração SW-SW Fabricação
Teste de Produção Teste de Produção

Integração Integração
Teste Integração SW-HW Teste Integração SW-HW
CI para o ususário CI para o ususário

Projeto e Produção de um Sistema Embarcado

Análise de Requisitos
Teste de um Sistema Integrado
Projeto do Sistema (Análise)
Projeto da Arquitetura do Sistema
Projeto dos Módulos
Partição Hardware/Software
Programação Planejamento do Teste
Teste unitário Síntese e Verificação
Teste integração SW-SW Fabricação
Teste de Produção

Integração Custo Custo

Teste Integração SW-HW (CTSW) (CTHW)
CI para o ususário
Teste de um Sistema Integrado Teste de um Sistema Integrado

Teste
SW

Teste de um Sistema Integrado Roteiro

Teste do Hardware
Por que teste integrado de HW e SW?
50% do custo de projeto e produção
Desafios para o teste de software embarcado
Teste do Software “Metodologia” de teste de software embarcado
50% do custo de projeto e produção
Grande responsável por atrasos
Técnicas de teste mais comuns
Proposta local
Teste do Sistema Integrado
Oh My God!!!!
Sistemas Integrados - Software
SOFTWARE EMBARCADO
software projetado e desenvolvido especificamente para
a execução em um sistema embarcado, geralmente
extremamente dedicado à aplicação
Sistemas Integrados - Software
SOFTWARE EMBARCADO
software projetado e desenvolvido especificamente para
a execução em um sistema embarcado, geralmente
extremamente dedicado à aplicação

HDS - hardware
Software de dependent
alto nível software

Conceptual Embedded Software Teste do SW em Sistemas

Organization Integrados
Boas técnicas de teste de SW não são
fáceis nem intuitivas
Diversas questões básicas
Teste de
SW Quando testar?
Quem testa?
De onde vêm (como criar) os casos de teste?
Teste de
Integração
Como avaliar o resultado do teste?
Quando parar de testar?
Filosofia do Teste Tipos de Teste
Criar bons casos de teste para seu próprio código é Funcionalidade
difícil testa o comportamento lógico
Várias empresas têm equipes separadas de testadores e
desenvolvedores Interfaces
Características pessoais diferentes Testa a interação com outros sistemas
Bons testadores são controversos
Interface com hardware (teste depende do hardware
Objetivos distintos disponível)
Objetivo do testador é “quebrar” o software
Regressão
Porém… Testa se modificações no sistema não introduziram falhas

Para software embarcado metodologias de projeto e teste Casos de teste derivados de falhas já descobertas
são ainda difíceis de implementar Modificações podem ser feitas com o produto em campo

Desafios para o Teste do SW em um

Tipos de Teste Sistema Integrado

Segurança Projetado e implementado por especialistas na aplicação

pouco ou nenhum domínio das técnicas de engenharia de software
Testa a robustez contra ataques
Qualidade do software é afetada
Ataques podem ser feitos via hardware
Código nem sempre estruturado
Recursos Estruturação (OO, por exemplo) custa caro
mede e verifica compatibilidade com recursos disponíveis Pouco ou nenhum reuso de teste

temporização e desempenho, memória, largura de banda… Há bastante pesquisa em modelos e ferramentas para projeto de SW
embarcado a partir de níveis mais altos de abstração
Carga e Stress Porém, código final a ser testado é sintetizado
verifica reação do sistema quando sobrecarregado
Sobrecarga no hardware (incluem-se questões de
variabilidade)
 Teste do SW em Sistemas
Roteiro Integrados
Boas técnicas de teste de SW não são
Por que teste integrado de HW e SW?
fáceis nem intuitivas
Desafios para o teste de sistemas integrados Diversas questões básicas
Processo de teste de software embarcado Quando testar?
Quem testa?
Técnicas de teste mais comuns De onde vêm (como criar) os casos de teste?
Proposta local Como avaliar o resultado do teste?
Quando parar de testar?

Visão Geral LITO

Abordagem estruturada comum TEmb generic :
Planejamento Many types of tests during system
Técnicas padrão development
Ambientes de teste For each test level, structured test
Documentação answers the questions:
What and when?
Características da aplicação How?
Mecanismos By what?
By whom?
Abordagem específica para
aplicação Lifecycle, Techniques, Infrastructure,
Organization
Lifecycle Techniques
How to do things
Standardized ways to perform certain activities

Example techniques:
Strategy development
Test design
Safety analysis
Which activities have to be performed and in what order Data driven test automation

Control over the process for testers and managers Checklists

Do as many activities as soon as possible

Infrastructure Organization
What is needed in the test environment to make it
possible to perform the planned activities
Defines:
the roles and required expertise of those
Test environment who must perform the planned activities
Facilities needed to execute the tests

The way they interact with other

Tools and test automation
disciplines
Facilities that support efficient test execution

Office environment
Facilities to housing the staff
Organization LITO
Structure of test organization At different stages in the lifecycle
Position of the test organization within the overall scheme the other three cornerstones will be
Internal structure of test organization (hierarchy of applied differently
disciplines, responsibilities, relationships)
Roles
Defines, for each discipline, the tasks, skills and expertise
required
Staff and training
How to get and keep personnel
Management and control procedures
Enables test process to handle changes

Temb Method Classes de Aplicações

Sejam duas características:
The TEmb – supports systematic approach to assembling
Safety critical
From a set of generic elements to produce ES-specific test approach
Technical-scientific algorithms
Underlying principle
A mapping from specific measures into specific characteristics of the
ES
The LITO (Lifecycle, Infrastructure, Techniques, Organization)
method is driven by
‘ the mechanism for assembling the dedicated test approach’
an analysis of ‘what, why, and how’
The ‘Mechanism’ defines ‘measures’ based on:
Business risks – factors that lead to failure of the ES
System characteristics – attributes that are ‘specific’ to the ES
functionality
Medidas Específicas Mechanisms

System Characteristics
Risk Analysis

Características do SWE definem as atividades (L), ferramentas (I),

técnicas de teste (T) e requisitos da organização (O)

System Characteristics Safety Critical Systems

What makes this system special and what must be
included in the test approach to tackle this? Failure can cause serioous damage to
health (or worse)
Initial (not exhaustive) set

Safety critical systems State-based behavior

Examples
Tech-scientific algorithms Hard real-time behavior avionics, medical equip, nuclear reactors
Autonomous systems Control systems
Unique systems Extreme environmental
Analog input/output conditions
Hardware constrained
Technical-scientific Algorithms Autonomous Systems

The larger and more complex part of
its behavior is internal and invisible
from the outside
Examples
cruise control or trajectory system
After starting up, they require no
human intervention or interaction
Examples
usually sent on a mission – robotic
Traffic signaling systems
Some weapons

Unique System Analog I/O, Mixed-Signals

“one-shot” development I/O do not have exact values but have

“bespoke systems” certain tolerances that defines the
custom-made acceptable boundaries
Released once and cannot be maintained Hard or soft boundaries
In contrast to mass market products that must
be upgraded regularly
Examples
calibrating devices where input/output
Examples
values are inexact
satellites
Hardware Restrictions
Limitations of HW resources
Memory, power consumption
Specific HW dependent timing aspects
solved in the SW
Examples
Cell phones, timers,...
Hard Real-time Behavior
The exact moment that input or output
occurs influences the system behavior
Requires timing analysis
Examples
space shuttle
State-based Behavior
Identical inputs are not always accepted
and/or may produce different outputs
Response depends on the history of previous
events
Examples
event driven, or where output depends on input
Control Systems
System output influences the environment,
which in turn influences the behavior of the
control system
The behavior of the system cannot be described
independently, without the enviroment
Examples
Industrial process control systems
Aircraft flight control systems
Extreme Environmental
Conditions
Exposure to extreme heat or cold,
mechanical shock, chemicals,
Specific Measures - Examples
Specific test design techniques to test state-based behavior
System is first modelled and the model is dynamically tested for
real-time behavior

radiation,... Dedicated tools for threat-detection

search for conditions in the input domain which may cause SW
failure

Examples Use of evolutionary algorithms for test case generation

Use of a controlling department when several simulators are
Satellites, avionics, search robots,… necessary
Quality and safety standards

LITO-Matrix LITO-Matrix
Project Lifecycle Project Lifecycle
System has different formats or “product-appearance”
A V-Model
a developmental model, which takes into account different physical versions
The model of the same system (the model, the prototype, and the product)

a simulated version of the embedded software on a conventional PC (e.g.,

using Rational Rose UML or Matlab)
The prototype
code generation from corrected model is then ported into a prototype
(experimental hardware or environment for the embedded software)
The Multiple-V Model
Where each physical version is tested completely, using the full testing
cycle or process
except where specific functionalities can’t be tested until later stages
some versions requiring specific techniques or environments

The final product

code is refined as experimental hardware is systematically/incrementally
replaced by actual hardware, and mass produced

Multiple V-Model Test Activities in the Multiple V´s

When can activities

best be executed?

Which test issues

are most relevant
at which stage in
the development
process?

Each of the product appearances (model, prototypes, final

product) follows a complete V-development cycle, including
design, build and test activities.
 Test-related Issues in the
Test-related Issues in the Model Prototype

Test-related Issues in the Product Roteiro

Por que teste integrado de HW e SW?

Desafios para o teste de sistemas integrados
“Metodologia” de teste de software embarcado
Técnicas de teste mais comuns
Proposta local
 Introduction

Safety Analysis Safety is the expectation that a system

does not, under defined conditions,
lead to a state in which human life is
endangered.

Safety Analysis Techniques Cause-Effect Relationship

Monitoring the system during design Effect = life endangerment FMEA

phase

FMEA
Failure Mode and Effect Analysis
FTA
Fault Tree Analysis
FTA
Cause-Effect Components
A failure mode describes the way in which a product
or process could fail to perform its desired function
desired function described by the needs, wants, and
expectations of internal and external customers.
A failure is the inability of a system or component to
fulfill its operational requirements.
Failures may be systematic or due to physical change.
An effect is an adverse consequence caused by a
failure mode.
Overview
Define the scope
Module, subsystem and/or system level
Build the risk classification table
Apply analysis techniques
FMEA, FTA
Failure Causes
fault (hardware and software)
an imperfection or deficiency in the system which may,
under some operational conditions, result in a failure
wear and tear (hardware)
environmental conditions such as electromagnetic
interference, mechanical, and chemical disturbance
(hardware).
Severity Categories
If a safety-critical system is under
development, a standard for failure
probabilities, damage, and risk classes
must be used
Examples
RTCA DO 178B (1992) for avionics
Own or industry stds.
Risk Chance of Failure

Risk = chance of failure x damage ranges

Risk classes

Damage Chance of Failure and Damage

For each combination of probability and severity

category, one can determine to which risk class it
belongs
Depends on the project, organization, usage of the system,
etc.
FMEA – Failure Mode and Effect
Analysis
Determines the effect of a failure mode on
the system
Corrupted data or unexpected behavior
System = end product (HW+SW)
Used early in the design process
FMEA Application Main Steps
Identifying potential failure modes
Determining the effects of these potential
failure modes on the functioning of the
system;
Formulating actions to diminish the effects
and/or failure modes.
FMEA Potential Benefits
Highly improved safety of the system;
The ability to track risks throughout the development
lifecycle;
Early identification of potential safety hazards;
Documented risks and actions to reduce them;
Minimizes late changes and related costs;
Produces a highly reliable input for the test strategy.
Identification of Potential Failures
Data failure modes
missing data
lost message, no data because of hardware failure ,…
Incorrect data
inaccurate, spurious,...
timing of data
old data, data arrives too soon for processing,…
extra data
data redundancy, data overflow,...
Identification of Potential Failures Describe Effect of Failure Mode
Event failures modes
1. Describe the direct effect at the function
halt/abnormal termination
hung or deadlocked,…
under investigation
omitted event 2. Description of the effect at system level
execution continuous while event does not take place,…
incorrect logic No discussion about whether the failure
preconditions are not accurate, event is not triggered as mode is possible
intent,...
timing/order Effects classified according to the ‘risk
event occurs at the wrong moment, or the ordering of classification’
events is wrong,
and usually based on assumptions

Identification of the Causes and

Measures Examples
For risks classified as http://www.fmeainfocentre.com/examples.htm
Intolerable
Undesirable
Tolerable with endorsement
Identify causes of the effects
For every cause, define measures to be
taken
Fault Tree Analysis - FTA FTA Symbols
Used for identifying causes of failures
Design analysis w.r.t. safety and reliability

‘The System Failure’ is usually the root of the fault tree

Which unwanted behavior (or parts of the system) is responsible for
the system malfunctioning?

System failure
incorrect event
incorrect data
unexpected data or behavior

FTA Method Example

The failure of the system is placed at the top of the

fault tree.
The next step is to determine what caused this failure.
Pacemaker
Every subsequent step looks at the cause of failure in
the previous step.
This analysis leads to a reason for the system failure.

Safety requirements are the baseline for deciding what

is unexpected or unwanted system behavior.
FTA is a job for an expert team.
Pacemaker Example Failures Types

AND-gates Single Point

for co-joined failure
OR-gates
single-point failure (these are sensitive to even a single
failure and could lead to a cascade of failure)
Any node can be used as a ‘root’ of another
(sub)FTA
allowing complex systems to be analyzed
e.g., R1 – Watchdog Failure, could be a root of another
FTA – if so, it is indicated by a ‘Transfer’ symbol)
Just one failure in the system leads to a cascade
of events and an unsafe situation
Common Mode Failures
Affect many parts of the system.
In a fault tree, these failures are the fundamental
cause of several conditions

Teste do SW em Sistemas
Integrados
Boas técnicas de teste de SW não são
Test Design Techniques fáceis nem intuitivas
Diversas questões básicas
Quando testar?
Quem testa?
De onde vêm (como criar) os casos de teste?
Como avaliar o resultado do teste?
Quando parar de testar?
Characteristics of TDTs
Black-box vs. White-box
Principles of test case derivation
Formal or informal
Application areas
Quality characteristics to be tested
Required type of test basis
STT: VCR Example
State Transition Testing
Some Test Design Techniques
State transition testing (STT)
Control flow testing (CFT)
Elementary comparison test
Classification-tree test
Evolutionary algorithms
Statistical usage test
Rare event test
Mutation analysis
VCR State-event Table

Control Flow Testing

Example Test Path Definition

Put the action combinations in ascending order
Action combinations
(1,2); (1,3); (1,4); (2,5); (2,6); (3,5); (3,6); (4,5); (4,6); (6,2);
(6,3); (6,4).

Link action combinations to create paths running from

the start to the end of the algorithm.
In this example, every path has to start with action 1 and end
with action 5.

Start with the first action combination that has not yet
been included in a path: (1,2).
Adds to the path the first action combination that starts
with 2 and has not yet been included in a path: (2,5).
Test Path Definition Test Path Definition
Remaining action combinations The remaining action combinations are
(1,3); (1,4); (2,6); (3,5); (3,6); (4,5); (4,6); (6,2); (6,3); (6,4). (2,6); (3,6); (4,6); (6,2); (6,3); (6,4).
Continue with the remaining action combinations. Continue
(1,3) followed by (3,5) The first action combination that has not yet been included in a
path is (2,6), which does not start at the beginning of the algorithm
This creates the path (1,3,5)
A preceding action combination must be determined - (1,2)
Remaining action combinations
Add action combination (6,2) .
(1,4); (2,6); (3,6); (4,5); (4,6); (6,2); (6,3); (6,4).
The test path is completed with combination (2,5), which creates
Continue with the remaining action combinations. test path (1,2,6,2,5).
(1,4) followed by (4,5).
This creates the path (1,4,5)

Test Path Definition

The remaining action combinations are
(3,6); (4,6); (6,3); (6,4). Elementary Comparison Test

The rest of the action combinations are included in test

path (1,3,6,4,6,3,5) and all action combinations have now
been included in the following paths:
Path 1: (1,2,5)
Path 2: (1,3,5)
Path 3: (1,4,5)
Path 4: (1,2,6,2,5)
Path 5: (1,3,6,4,6,3,5)
Function Description
Describe unambiguously the decision paths and related aspects
Identify the conditions (DO, IF, REPEAT, ...) Classification-tree Testing
Give a unique identification
Only the conditions driven by data input are considered

Example Partitioning into Input Domains

Can be a recursive activity
Cruise control software

Aspects considered
Speed of the car
Difference between current and desired speed
Cruise control reacts to cars in front of it
Difference in speed and distance between cars
Logical Test Cases
Embedded SW test
Environement

Teste do SW em Sistemas
Integrados Test Process
Boas técnicas de teste de SW não são
fáceis nem intuitivas
Diversas questões básicas
Quando testar?
Quem testa?
De onde vêm (como criar) os casos de teste?
Como avaliar o resultado do teste?
Quando parar de testar?
Simulation Stage Simulation Stage

Early models simulate the system Model-based design and test

Model tests and model-in-the-loop tests Proof of concept
Design optimization
Rapid prototyping Test tools
Experimental model with high Petri nets
performance capacity and plenty of Formal verification
resources in a real-life environment
Model checking

Test Process Prototyping Stage

“software-in-the-loop” testing (SiL)

checks the real software including all resource
restrictions
16-bit or 8-bit integer processing
simulated environment or with experimental
hardware.

“hardware-in-the-loop” testing (HiL)

Real hardware is used and tested in a simulated
environment
Prototyping Stage
Goals of the test at this stage
Proving the validity of the simulation model
Verifying that the system meets the requirements
Actual system HW, computer HW and SW
components replace simulation model gradually
HW/SW Integration Tests
Test object is a hardware part on which the integrated
software is loaded.
The software is incorporated in the hardware in
memory
Goal
verify the correct execution of the embedded software on the
target processor in co-operation with surrounding hardware.
“hardware-in-the-loop”
Because the behavior of the hardware is an essential part of
this test
SW Unit and SW Integration Tests
Test object is an executable version of a software
unit, or a set of integrated software units
developed on basis of the design or generated from the
simulation model.
Host/target testing
System Integration Tests
All the hardware parts that the embedded system
contains are brought together
generally on a prototype printed circuit board.
Goal
verify the correct operation of the complete embedded
system.
the prototype printed circuit board of the complete
system is provided with its final I/O and power supply
connectors
Test Process Pre-production Stage
Construction of a pre-production unit

“system test” (ST)

the real system is tested in its real
environment

Pre-production Stage Pre-production Stage

Goals Types of testing
system acceptance test;
To finally prove that all requirements are met. qualification tests;
To demonstrate conformity with environmental, industry, ISO, safety execution tests;
military, and governmental standards. tests of production and maintenance test facilities;
inspection and/or test by government officials.
To demonstrate the system can be built in a production
environment within the scheduled time with the scheduled
effort. Applicable test techniques are:
To demonstrate the system can be maintained in a real-life real-life testing;
environment and that the mean-time-to-repair requirements random testing;
are met. fault injection.
Demonstration of the product to (potential) customers.

Roteiro
Por que teste integrado de HW e SW?
Desafios para o teste de sistemas integrados
Desafios para o Teste do SW em
um Sistema Integrado
Para o HW-dependent SW
Análise do código (uso de ferramentas de teste)
não produz resultados significativos

Processo de teste de software embarcado

Técnicas de teste mais comuns
Proposta local

.... ....
sensor_get(&vertical_veloc_sensor); sensor_get(&vertical_veloc_sensor);
sensor_get(&horizontal_veloc_sensor); sensor_get(&horizontal_veloc_sensor);
.... ....

void sensor_get(float* data)

{
(*data) = memory[r1]&mascara;
...
}
Desafios para o Teste do SW em Desafios para o Teste do SW em um
um Sistema Integrado Sistema Integrado

Para o HW-dependent SW Para o HW-dependent SW

Análise do código (uso de analisadores Análise do código (uso de ferramentas de teste) não produz
resultados significativos
estáticos) não produz resultados significativos

Análise dinâmica (análise de cobertura) depende

Análise estática insuficiente
de um simulador ou
numerous modifications in the source code
Inability to understand and deal with automatic build de uma Plataforma de execução real
process
elevated number of false positives and misleading PORÉM....
results

Desafios para o Teste do SW em um Desafios para o Teste do SW em um

Sistema Integrado Sistema Integrado

Simulador da plataforma de hardware

Novo simulador para cada novo hardware?
Validação do próprio simulador é um problema

Plataforma de execução real (protótipo)

Construída junto com o SW!

Ainda que existam...

.... ferramentas de teste existentes não conversam com

esses recursos...
 Nossa proposta Fundamentos
Considerando o software de aplicação e o HW-
dependent SW
Propor um nova metodologia de teste de
software para sistemas embarcados que: Rotinas dependentes do HW são normalmente
simples

Permita reuso de testes utilizados anteriormente Possibilidade de injeção de falhas e avaliação

Use estratégias já existentes de testes da qualidade do teste e do software
Se desvincule ao máximo do hardware independente da plataforma
Utilize ferramentas já existentes e fáceis de usar

Metodologia Proposta Metodologia Proposta

ANÁLISE DO HARDWARE E ANÁLISE DO HARDWARE E
IDENTIFICAÇÃO DE TODOS OS IDENTIFICAÇÃO DE TODOS OS
DISPOSITIVOS FÍSICOS QUE SERÃO DISPOSITIVOS FÍSICOS QUE SERÃO
ACESSADOS ACESSADOS

IMPLEMENTAÇÃO DAS FUNÇÕES DE

ACESSO AOS DISPOSITIVOS DE
MODELO DA APLICAÇÃO

MODELO DA APLICAÇÃO
HARDWARE COMO ABSTRAÇÕES DO
HARDWARE REAL (MODELAGEM EM
ALTO NÍVEL)
 Metodologia Proposta
ANÁLISE DO HARDWARE E
IDENTIFICAÇÃO DE TODOS OS
Metodologia Proposta
DISPOSITIVOS FÍSICOS QUE SERÃO
ACESSADOS

IMPLEMENTAÇÃO DAS FUNÇÕES DE

ACESSO AOS DISPOSITIVOS DE
MODELO DA APLICAÇÃO

HARDWARE COMO ABSTRAÇÕES DO

HARDWARE REAL (MODELAGEM EM
ALTO NÍVEL)

IMPLEMENTAÇÃO DO SOFTWARE DE
APLICAÇÃO, UTILIZANDO
CHAMADAS AS FUNÇÕES DE
ACESSO AO HW JÁ
IMPLEMENTADAS

Metodologia Proposta
ANÁLISE DO HARDWARE E
IDENTIFICAÇÃO DE TODOS OS
Metodologia Proposta
DISPOSITIVOS FÍSICOS QUE SERÃO
ACESSADOS

IMPLEMENTAÇÃO DAS FUNÇÕES DE

ACESSO AOS DISPOSITIVOS DE
MODELO DA APLICAÇÃO

HARDWARE COMO ABSTRAÇÕES DO

HARDWARE REAL (MODELAGEM EM
ALTO NÍVEL)

IMPLEMENTAÇÃO DO SOFTWARE DE
APLICAÇÃO, UTILIZANDO
CHAMADAS AS FUNÇÕES DE
ACESSO AO HW JÁ
IMPLEMENTADAS

VALIDAÇÃO DA APLICAÇÃO
ATRAVÉS DO USO DE
FERRAMENTAS DE TESTE DE
SOFTWARE
 Metodologia Proposta
ANÁLISE DO HARDWARE E
IDENTIFICAÇÃO DE TODOS OS
DISPOSITIVOS FÍSICOS QUE SERÃO
ACESSADOS
IMPLEMENTAÇÃO DAS FUNÇÕES DE
ACESSO AOS DISPOSITIVOS DE
MODELO DA APLICAÇÃO
HARDWARE COMO ABSTRAÇÕES DO
HARDWARE REAL (MODELAGEM EM
ALTO NÍVEL)
IMPLEMENTAÇÃO DO SOFTWARE DE
APLICAÇÃO, UTILIZANDO
CHAMADAS AS FUNÇÕES DE
ACESSO AO HW JÁ
IMPLEMENTADAS
VALIDAÇÃO DA APLICAÇÃO
ATRAVÉS DO USO DE
FERRAMENTAS DE TESTE DE
SOFTWARE
Metodologia Proposta
Metodologia Proposta
ANÁLISE DO HARDWARE E
IDENTIFICAÇÃO DE TODOS OS
IMPLEMENTAÇÃO DAS FUNÇÕES DE DISPOSITIVOS FÍSICOS QUE SERÃO IMPLEMENTAÇÃO DAS FUNÇÕES DE
ACESSO AOS DISPOSITIVOS DE ACESSADOS ACESSO AOS DISPOSITIVOS DE
HARDWARE - HDS HARDWARE - HDS
IMPLEMENTAÇÃO DAS FUNÇÕES DE
VALIDAÇÃO DO HDS NA ACESSO AOS DISPOSITIVOS DE VALIDAÇÃO DO HDS NA
MODELO DA APLICAÇÃO
PLATAFORMA ALVO HARDWARE COMO ABSTRAÇÕES DO PLATAFORMA ALVO
HARDWARE REAL (MODELAGEM EM
ALTO NÍVEL)
INTEGRAÇÃO DO HDS ÀS FUNÇÕES
IMPLEMENTAÇÃO DO SOFTWARE DE DE ACESSO AO HW MODELADO
APLICAÇÃO, UTILIZANDO
CHAMADAS AS FUNÇÕES DE
ACESSO AO HW JÁ
IMPLEMENTADAS
VALIDAÇÃO DO SOFTWARE
INTEGRADO NA PLATAFORMA ALVO
VALIDAÇÃO DA APLICAÇÃO (teste de regressão)
ATRAVÉS DO USO DE
FERRAMENTAS DE TESTE DE
HDS – hardware dependent software SOFTWARE HDS – hardware dependent software
Experimental Results
 Advantages Considerações Finais
Takes advantage of the body of knowledge of the development
team
Diversos aspectos a considerar
Transforms it into a persistent and reusable design artifact Sistema operacional
Allows the definition and evaluation of unit, integration, and system RTOS
tests early in the design process
Sistema em evolução
leverages the need for multiple versions of the software
Mudanças de requisitos, funcionalidades, etc. durante a
one for simulation and test and another one for deployment
vida útil
leverages the need for the target platform in the initial design
phases Model checking & test
brings flexibility for the design team Exploração dos modelos para teste do código
explore up-to-date design and test tools as well as different platforms
Modelo de falhas para ESW
with minor changes in the application code.