-
Uma Proposta de Sistem;iitica para a Anse de Segurana de
soRwareCrftico Embarcado Aeroespacial
Elio Lovisi Filho^PPI InforrI:iatica Ltda Rio de Janeiro -
RJ
(021) 540 9100 [email protected]
Adilson Marques da CunhaDivis2o de Ci8ncia da CompsSo Instituto
Tecnol6gico de Aeronautic& S&o Jose dos Campos - SP
(012) 347 5896 [email protected] cta br
AbstractIn spz"te of the increasing "mtegran"on of Computers
intoAerospace Systems, rhere is no evidence of existing
effectz"veSystematic for real"Ize the Analysis of Aerospace
EmbeddedCntical sofhvare, able to aid in obtain appropr"zaze levels
ofsoftWare Safe1y" The lack of this kind of SystemaLz"c
besidesincreasz"ng sofiware compLexz`ty, cost and deveLopment
timehas caused considerable waste of resources. This
articlepresents the nzain ideas being investigated to compose a
newSystemalic for Analysis, that attends sojtware
Safetyrequz"rements. The authors believe that acceptable levels
forthe Safezy of Aerospace Embedded Critical soare can beonly
obtained if.new solutions arefoundfor soare Safetyproblems. The
Systematicfor Analysz.s proposed in thisarticle z"ntends zo
represent an added value eOrr into thisdirection"
Figura 1: Utiliza8o de Software Embarcado no Program&
1 IntroduoAtualmente, observa-se uma crescente incorporaAo
doscomputadcres aos Sistemas Aeroespaciais, utilizado-se omesmo
para a realizao das mais diversas funV6es. Umaimportante aplica50
do computador nesses sistemas e oapoio aos processos de controle e
tomada de deciso,proporcionando considerdveis ganhos tanto
nodesempenho quanto na eficcia dos SistemasAeroespaciais.
0 emprego dos computadores para auxnio ao controlede Sistemas
Aeroespaciais exige uma aten80 especial emrela5o Segurana, uma vez
que estes sistemas sAoconsiderados como Crfticos, pois uma falha no
senfuncionamento pode lever a grandes perdas, tanto deordem
econ6mica. como ambiental ou humana.
A Figura 1, a seguir, apresenta o crescimento do usode software
Embarcado em um import&ate tipo deSistema Crftico-
Espacial Norte-Arnericano.[Moura e Santellano, 19991
90
Mi|hoes de~ so
lnstru9oesno C6digo 40
objeto
10
1990 lO$S 1970 197$ 1990 1999 1990 199$
AnO
QuaTIC'2001 / 147
-
Pode-Se observer, na Figura 1, um crescimentoexponencial do
emprego de software no programaAeroespacial norte-americano.A
crescente utiliza5o dos softwares Ctfticos Embarcadosnos Sistemas
Aeroespaciais devese, principalmente, aodesenvolvimento da
tecnologia digital, ao controlecomputadorizado de tarefas,
reusabilidade do software,it miniaturizano, ix reduAo de custos e
it facilidade deintegraKO dos Sistemas computadorizados.
0 emprego de computadores para apoio aosprocessos de controle e
decisAo de SistemasAeroespaciais salienta a necessidade de se
desenvolver ouadapter novas tecnologias, compostas de
m6todos,tecnicas, ferramentas e mdtricas, para garantir aSegurana
dos mesmos. Busca-se assim evitar que umafalha do computador venha
a comprometer ofuncionamento ou desempenho de todo o
sistema.Considera-Se o software como o componente de umcomputador
mais passivel iz ocorr8ncia de falhas, exigindoa realiza5o de sen
desenvolvimento com Garantia deSegnrana, ou seja, garsUndo que. o
mesmo, i funionarem um szstema sem resuJtar em rxscos znacextavezs.
bssetipo de estudo faz parte da area de Segurana de
software(software Safety).Neste artigo propoee..Se a definio de uma
Sisternaticapara a realizao de uma Analise de Segurana de
umsoftware Crftico Embarcado Aeroespacial (SCEA),deterrninando-se
as restriJes de Seguranqa de softwarepara este tipo de
aplica20.
2. Seguran de Software
De acordo com o que foi apresentado anteriormente, aSegurana de
software envolve estudos para garantir Queo software execute suas
funJes sem acarretar riscoinaceitdvel para a Segurana do sistema,
dos usuariOs e domeio arnbiente em Que o sistema estd
inserido.Portanto, pode-Se considerer a Segurana de softwarecomo um
fator explfcito de Qualidade, uma vez que, casoeta no se verifique
para um software ele ago atenderd expectativas do usuo [Lovisi e
Cunha, 1999].A Garantia de Seguranga de software comp5e-Se de
umaseqO8ncia de atividades planejadas que visam assegurar
aimunidade da aplicaAo de software em rela5o apossibilidade de
ocasionar acidentes que comprometarn aVida humana, o meio ambiente,
ou a propriedade [Moura1996].Define-se EstrateSia de Segurana de
software como umconjunto de atividades que visam garantir que
aSegurana de software e devidamente tratada nodesenvolvimento ou
manuten(;:2o do mesmo. O padrAoMIL -STD 498 recomenda a definiAo de
urnaSisterndtica de Segurana como estraregia de Seguranade software
[Santellano et aI, 1998].Neste artigo serd apresentada uma
Sistem5tica paraAnise de Segurana, que Se aplica somente durante
o
desenvolvimento do software Critico. Dessa forma,procura-se
atestar nfveis mais adequados de Segurana aoprocesso de
desenvolvimento de software, desde asprimeiras lases de sua
concep20.Para o desenvolvimento deste estudo, d
accessarioapresentar algumas definiJes relacionadas it Seguranade
software [P6rto e De Bortoli, 1997; Ippolito eWallace, 1995]:
. Acidente (Mishap) e um evento n5o planejado quacausa perdas
humanas, danos ao meio ambiente oudanos aos equipamentos;
. Defeito (Fault) uma imperfeio existente noco
-
desenvolvimento, visando tratar o problems da Seguranade
software desde o inicio de sua implementa&o.Nessa lase busca-se
determiner e availer as falhas dosoftware que possam levar o
Sistema, que ele faz pane, aum Estado Inseguro. A Analise de
Segurana de softwarepossui grande impolnlncia, principalmente para
softwarescomponentes de Sistemas Criticos. Essa amilise
6desenvolvida a partir das informaJes obtidas na Analisede
Sisternas.Enquanto a lase de Andlise de Sistemas de umametodologia
visa a identificago das fung6es que osoftware deve executer, a
'Amiuse de SeguranVaconcentra-Se em qua o software mio deve
executar
veson, 199 I)-Para realizar esta aruilise com sucesso
necessitasetambem de uma sisterndtica hem defmida, composts
demtodos e tecnicas, objetivando a identificaq&o e aavaliaV5o
dos Estados Inseguros.
No pr6ximo item, apresenta-se as atividades Queconstituem a
An;nise de Segurana de software, de acordocom Os estudos publicados
nas refer8ncias [leveson,1991; Leveson e Harvey, 1983; Moura,
1996).
4 Antilise de Segumn de Software
Como apresentado anteriormente, a Analise de Seguranade software
baseia-se em determiner quais situsJespodem levar o Sistema a um
Estado Inseguro. Esta anisepossui diversas atividades, visando:
identificar os EstadosInseguros e as falhas que os originaram;
determinar oFator Cntico (Criticality) dos mesmos; e ainda,
av&liar aaceitabilidade dos niveis de Seguran do Sistema.A
Figura 2 a seguir apresenta codas as atividadescomponentes da
Analise de Segurana de software, hemcomo as informa6es de entrada e
de saids de cada umadestas atividades
Ca um
Riscos
R
Figura 2: ProcedimenW para Ane de Segnran de Software
QuaTIC`2OOI / 149
-
As atividades da Analise de Segnrana de software devemse repetir
k medida Que a quantidade de inform&Besaumenta; logo, o se pode
esperar Que as mesmas,obedeam a nma rigid& ordem cronol6gica,
devendoSereviser estas anuses a cada modifies&o no projeto
dosistema.No inicio do desenvolvimento de um software
Cn"dcoEmbarcado, elabora-se a Lista Preliruinar deInsegnranas,
contendo as possiveis falhas para este tipode software. Esta Esta 6
desenvolvida a partir deinform&6es existentes sobre Analises de
Segurana desoftware sirnilares.A medida que o desenvolvimento
avanga realizam-seontras anlises tamb6m para a identificao dos
EstadosInseguros e de suas falhas causadoras:
* A Andlise Prelirninar de Insegurana(Preliminary Hazards
Analisysis), Que visadeterminar os snbsistemas criticos e Se
possivelpropor alternativas de controle. Baseia-Se nosdados
existentes e na experi&ncia dos analistaspara desenvolver urns
andlise em alto nine) dasprincipals funJes e interfaces;
* A Analise de Insegurana de Subsistemas(Subsystem Hazards
Analisysis) objetiva aidentificaAo dos Estados Inseguros e suas
falhasno projeto de cada snbsistema e de sna interface.Concentra-se
basicamente em aspectos tais como:desempenho, degradaAo no
funcionamento efalhas funcionais, procurando determiner os modosde
falhas e sens efeitos;
* A Arui1ise de Insegurana de Sistema(System Hazards Analysis)
identifica os EstadosInsegnros e suas falhas, associados as
interfacesentre os subsistemas, incluindo erros potenciaishumanos;
e
* A An~ise de Insegurana na Operao eSuporte (Operation and
Support Hazard Analysis)avails os Estados Inseguros ocorridos
dnrante asetapas de nso e manutenAo do sistema,especialmente
aqueles provenientes da intera50do homem com o Sistema.
Para realizer estas anaUses, 6 necessa a utiliza50 dealgumas
t6crlicas para identificaVAo de Estados Inseguros,tms como: Hazop;
SFTA; FIvfECA e Redes PetriTemporals [Ippolito e Wallace,
1995].Como as t6cnicas para Anise de Segnrana de softwareSAD
adaptadas de outras reas da tecnologia, geralmente 6necessaria a
utilizeo conjugada das mesmas, para aidentifica80 apropriada dos
Estados Inseguros.Dene-se lamb6m conhecer as caracteristicas
pecnliares dotipo de aplica80 em desenvolvimento, para determinar
astnicas mais adeqnadas a Setern utilizadas nas anauses desegurana,
observandose tamb6m, as potencialidades erestri6es das mesmas.
Cabe A Sistemdtica para AndIlse de Segurana, determinaras
t6cnicas a serem aplicadas e a seqn8ncia de utiliza&odas
mesmas, de acordo com as caracteristicas daaplica50"Ap6s a
identificao dos Estados Insegnros, realiza-seurna avalia80 dos
mesmos quanto ao sen Fator Critico,considerando fatores como
Severidade do acidenteativado pelo Estado Inseguro e sna
Probabilidade deocorr8ncia [Leveson, 19911.A determina&o do
Fator Critico dos Estados Insegurosconsiste em classificar Os
mesmos, de acordo com aSeveridade (Severity) do acidente causado
por eles(Catastr6fico, Crltico, Marginal e Menor) e aProbabilidade
(Probability) de ocorr6ncia deste acidente(Freqacute, Provdvel,
Ocasional, Remote e Improvvel).A Tabela I mostra a classificaSo dos
Estados Insegurosquanto ao Fator Critico proposta no padr5o
britAnico IntDef Stan 00-56 [Ministry of Defense, 19971.
Fator Critic.Tipo de Severidade
Faixa deProbabihdad
Camstr6fica
CIib"Ca Marginal Desprezi-vet
Freqiiente T4 T4 T3 T2PrOvgvel T4 T3 T3 T2OCaSiOS2I T3 T3 T2
T2Remom T3 T2 T2 TlImprovvel T2 T2 Tl Tl
Tabela 2 - Cla[ssificao do Acidente quanto ao Pater
Critico [Ministry of Defense 19971Cada nfvel de Fator Critico
exige nm tratamentodiferenciado para garantir a Segurana do
software. Porexemplo, um estado do nine! T4 necessita de
atenAoespecial exigindo a utilize50 de estrnturas deprogram&o
para evitar, controlar on recuperar suaocorr&ncia, ao passo
que, um estado do nivel Tl pode nAodernandar tantos
cnidados.Dene-se observar lamb6m Que, devido it falta de
dadosnum6ricos para o software, geralmente desconsidera-se asua
classificaAo qnanto k probabilidade.Ap6s o t6rmino da determina8o
do Fator Critico,avaliam-se os Estados Insegnros nAo
evitados,control&dos ou recnperados comp3etamente,
paradeterminer se os mesmos realmente n5o representam umaameaa it
Segurana de software, garantindo assim, Que omesmo apresenta urn
nivel aceinivel de risco.
5 Software Crifico Embarcado Aeroespacial -SCEA
As consider&Jes realizadas at6 ennlo, nAo se relacionarna
nenhnm tipo peculiar de software. A partir deste ponto,
-
aborda-se neste artigo, apenas os softwares CriticosEmbarcados
Aeroespaciais (SCEA`s)"Denornina-se software Critico, aquele
utilizado emcompntadores componentes de Sistemas Criticos. Estetipo
de software exige urn desenvolvimento cuidadosopara garantir a
Segurana de software necessa, pois,uma falha na sua execuBo pode
originar um acidentecom grandes perdas humanas, econ6micas e
ambientais-Um software Critico Embarcado Aeroespacial (SCEA)
eempregado em computadores Embarcados em SistemasAeroespaciais. E
importante ressaltar que essa classeengloba, tanto o software
componente de computadoresEmbarcados nas Aeronaves, quanto queles
utilizados nosequipamentOs de solo [Moura e Santellano, 1999].Essa
aplicao particular do software Critico Embarcado,exerce as mats
diversas funV6es em SistemasAeroespaciais, principalmente, o apoio
ix tomada dedecis5es e controle de outros componentes.Dene-Se aqui
ressaltar a diferena entre um software paraaplicago civil, onde 6
necessdrio evitar a ocorr8ncia deacidentes que possam causar perdas
de vidas, de umsoftware para aplica5o militar, onde 6 necessario
garantirque o Sistema ir:i completer sua miss&o com xito.
5.1 As Caractensticas do Soare Cn�tz"coEmbarcado Aeroespacz-al -
SCEA
O software Crftico Embarcado Aeroespacial (SCEA),atualmente,
Vern sendo empregado em novas funV6es parao software, em
substituiilo a componentes eletr6nicosQue apresentam aka
Confiabilidade e Segurana.Como os Sistemas Aeroespaciais possuem
alto FatorCritico, os sens componentes de software possuemalgumas
caracteristicas peculiares, de acordo com[Parnas, 1986; Moura et
al, 1996], Que devem serobservadas para o sen desenvolvimento.Esse
tipo de software possui algumas restriJes emreJao ao tamanf o do
c6digo, ix capacidade da mem6ria eao uso do processador. Ele deve
iamb6m, implementertcnicas qne permitam a recupera5o de dados
perdidosou danificados por interferncia eletromagn6dca nohardware-A
utilizao do software Critico Embarcado em SistemasAeroespaciais,
geralmente, objetiva: a execuAo decomplexos cdlculos materndticos,
mnitos dos quais miopodem ser realizados por seres hnmanos em tempo
hdbil;a realiza2o de opera6es de auxilio e monitoramento docontrole
de todo o Sistema; a entrada de dados noSistema; e a implementaV5o
do controle das funJesbdsicas do Sistema.O software deve ter alta
qualidade, confiabilidade,segurana e toleriincia a falhas, pois
qualquer erro em suaexecu5o pode levar a um acidente com grandes
perdas.
5.2 0 Desenvolvz-mento do soare CnoEmbarcado Aeroespacial -
SCEA
Devido ixs caracterfsticas do software Cxitico
EmbarcadoAeroespacial, algumas recomendaJes principais devemser
observadas para o sen desenvolvimento, a saber: autiliza5o de um
enfoque metodol6gico para odesenvolvimento do software; a adoV:5o e
adaptaAo depadr5es Que provm consideraJes sobre segurana; ouso de
ferramentas CASE para apoio ao desenvolvimento;e uma documenta5o
Clara e abrangente de todo projeto[Parnas, 1985; Parnas, 1986;
Leveson e Harvey, 1983;Moura et al, 1996]-AI6m disso, a ad5o de
procedimentos de testessistemdticos com uso de simuladores de
software e deestrat6Bias de certifica50, uma avalia5o quantitativa
dosoftware e a utiliza5o de m6todos formais podem sernecessariOs,
de acordo com o grau de Confiabilidade e deSegnranVa exigidos do
software.Um estudo das interdependncias entre software ehardware,
levando em consideraAo as caracteristicas daaplicaV5o, e tamb6m uma
investigaAo dos acidentesenvolvendo softwares semelhantes podem ser
importantesfontes de informaV5o, permitindo a identifica20
dasfraquezas e prioridades do processo de desenvolvimento.A
abordagem desse trabalho de pesquisa concentra-Seexclusivamente, na
Andlise de urn SCEA, visandoobserver a Carantia de sua Segurana-
Para isso, deve-seutilizar uma Sistemdtica para Andlise Que
propicie aidentifica e a avalia50 dos Estados Inseguros.auxiliando
assim na garantia de niveis apropriados deSegurana aplicaV5o.
6 Sisteroanca para Anse de Segurana deSoftware Critico Embarcado
Aeroespacial
A partir das caracten�sticas do SCEA apresentadas no
itemanterior, desenvolveu-se a Sistexmitica para realizaBo
daAnalise de Segurana deste tipo de software. Estasistemdtica
determine as t6cnicas mais adequadas para arealizaAo da amilise e a
sequencia de utilizao dasmesmas.Como citada anteriormente, a Anise
de Segurana desoftware inicia-se com a prepara5o de uma
ListsPreliminar de Inseguranas. Esta lista tamb6m pode serelaborada
na lase de AmiIlse de Requisitos, integrando asrestriV6es de
Segurana aos requisitos do Sistema.A partir da Lista Preliminar de
Inseguranas, realiza-se aAnise Preliminar de InseguranVa, visando
distinguir OsSubsistemas Criticos. 0 produto dessa andlise 6 uma
lista,contendo os componentes criticos do Sistema e senspossfveis
Estados Inseguros.A Analise de Insegurana de Subsistemas
buscaidentificar novos Estados Inseguros nos SubsistemasCriticos,
utilizando para isso as t6cnicas: Andlise de
QuaTIC,2001 ! 151
-
Modos de Falhas, Efeitos e Fatores Cn-ticos (FailureModes,
Effects and Criticality Analysis - FMECA);Analise de ore de Falhas
(software Fault TreeAnalysis - SFTA); e Redes Petri Ternrais.0
emprego da T6cnica de AnldIlse de Arvore de Falhas desoftware
(software Fault Tree Analysis - SFTA) envolve aconstru80 de um
diagrama l6gico, mostrando a provavelseq"d6ncia de falhas Que leva
a um determinado EstadoInseguro [Ippolito e Wallace, 19951.A
T6cnica de Analise de Modos de Falha, Efeitos e FatorCritico
(Failure Mode, Effects and Criticality Analysis -FMECA) envolve a
utiliza5o do raciocfnio indutivo paradeterminar o efeito no Sistema
da falha de umcomponente em particular, incluindo instruJes
desoftware [Ippolito e Wallace, 1995],Pode tarnb6m utihzar-se a
t6cnica Andlise de Rede Petri-Temporal [Leveson e Stolzy, 1987], k
qual cria umarepresentaAo grfica do Sistema Que pode
serinspecionada para a determinaViio de fa\bas relacionadas
atempo.
As atividades pertencentes ix An:Uise de Insegurana deSistema
visam identificar Estados Inseguros relacionadosk interno do
computador com outros componentes doSistema. Para tanto, prop6e-se
o desenvolvimento de umaSMFE, para integrar os resultados das
t6cnicas FMECA eSFTA.A utilizaRo conjugada de SFTA e 'FMECA
perrniteanalisar as causas e os efeitos de cada falha do
software,armazenando essas informaJes em uma tabeladenominada
Sumario de Modos de Falhas e Efeitos(SMFE) [Moura,
1996].Finalmente, realiza-Se a Andlise de Insegnrana naOperaAo e
Suporte para identificar os Estados Inseguros,o uso e a rnanuten2o
do Sistema. NAo prop6e-Senenhurna t6cnica especffica para esta
AndIlse, podendorea)iza-la a partir da investigaSo do SMFE.Ap6s a
identifica20 dos Estados Insegnros, deve-Seavalid-los e
classificlos de acordo com o sen FatorCritico. Para tanto,
considera-se fatores como Severidadee Probabilidade de ocorrencia
do acidente associada acada Estado Inseguro, como exposto no Item
4.No final deste procedimento, deve-se avaliar Os EstadosInseguros
n5o evitados, controlados on recuperadoscompletamente, visando
garantir Que os mesmos n5orepresentem uma ameaa a Segurana de
software.A Figura 3, a seguir, mostra uma sintese da
Sistematicapara Anlise de Segurana de software.
Lista Prelirninar de Insegurancas
Identificao |dos Estados !Inseguros e [suas Falhas ~
etDeterrninaco do Fator Critico dos Estados Inseguros
Resnltado
FigIra 3: Sistenldtica para Andlise de Seguran de Software.
152 / QuaTlC':2001
-
A figura acima sumariza a Sistermitica para Analise deSegurana
de SCEA, apresentando toda seqO8ncia deatividades e t6cnicas
constituintes desta antilise. Ressalta-Se que a realizaAo destas
andlises d iterativa, reavaliandosens resultados ix medida que as
informaJes sobre osistema aumentarn.
7. Conclus6es e Recomenda6es
Apesar da crescente importSncia dos computadores nasociedade
moderna e de sua integra20 aos SistemasAeroespaciais. ainda n5o Se
tinha noticia da existencia deuma Siscemzitica eficaz para a
AnaZise de softwaresCriticos Embarcados Aeroespaciais, capaz de
auxiliar naobten8o de niveis apropriados de Segurana de software.A
falta de uma Sistematica deste tipo, vinha aumentandoa
complexidade, o custo e o tempo de desenvolvimentodestes
softwares.Neste artigo, apresentou-Se uma proposta de
Sistematicapara Anlise de Segurana de software Cn�tico
EmbarcadoAeroespacial (SCEA). Esta nova Sistexmitica
possuidiferentes atividades para identificado de EscudosInseguros e
das falhas quo Os originaram, determinaq5odo Fator Critico, e
ainda, avaliao da aceitabilidade dosniveis de Segurana do
Sistema.Dessa forrna busca-Se auxi2iar no incremento do nine/
deSeguranVa de software exigida para este tipo de aplica20, desde
as primeiras lases de sen desenvolvimento.A realiza&o
criteriosa deste procedimento de Andlise deSegurana de software,
pode reduzir o esforo dedetec5o e corr80 de defeitos, reduzindo
tamb6m, oesforo para o desenvolvimento do SCEA.Pode-Se considerer o
uso da tecnica Ar[dlise de Rede PetriTemporal facultativo, ulna vez
Que, a mesma s6 apresentarosultados signiflcativos em softwares com
restri6esseveras em relao ao tempo e a sincroniza5o, e nemtodos os
SCEA possuem estas caracteristicas.Recomenda-se tamb6m, o
aprimoramento das ferramentasCASE e das tecnicas para Antj2ise de
Segurana desoftware, permitindo melhor observer a interaVo
dosoftware com os outros componentes do Sistema.Dene-se tamb6m,
desenvolver Sistemtitleas como a desteartigo, quo Se apliquem ao
Projeto e ix Implementa&o doSCEA. Busca-Se assim, abranger todo
o ciclo dedesenvolvimento do software.A curto e mddio prazos,
pretende-Se aplicar estaSisterDxaflea para Analise de Segurana de
SCEA emprojetos do ITA (Instituto Tecnol6gico de
Aerondutica),visando fornecer meios que possibilitem o acr6scimo
nosmveis de Segurana no desenvolvimento de SCEAs
nestainstitui80.Posteriormente, pode-Se utilizar a Sistematica
propostaneste trabalho em disciplinas relacionadas a Engenhariade
software e Qualidade de software, visando qualificarum ndmero valor
de profxssionais para odesenvolvimento de SCEA.
FERNANDES A. A. Ger&ncia de sofrware Atravks de
Mer"rzcas,Garantx.ndo a qualidade do Projeto, processo e
produto.Atlas Ed., Sa-o Paulo, 1995.
GHEZZI C., JAZAYERI M.. MANDRIOLI D. Fundamentals ofsoftware
Enginee.rxng- Prentice-Hall Inc.. New Jersey , 1991.
IPPOLITO L" M. , WALLACE D. R. A Study on HrdAnalysz.s in High
Integrity sofrware Standards andGuidelines. National Institute of
Standards and Technology.Disponivelpor meio da www no
endereohttp://bissa
ncsl.Dist.govtHHRFdata/Artifacts/lTLdoc/5589/hazard.htrnl. Janeiro
de1995.
LEVESON N. G. sofhvare Safety in Embedded ComputerSystems.
Comunications of the ACM, Fevereiro de 1991, p,35 - 45.
LEVESO N. G. , HARVEY P. R. Analyzing so.fi-Ware Safety.IEEE
Transactx`ons on software Engineering , Setembro de1983. Vol- SE-9,
no 5.
LEVESON N. G., $7012 Y J. L. Safety Analysis Using PetriNets.
IEEE Transactions on software Engineering , Marode 1987, Vol. SE-
13, no 3.
LOVISI FllflO E., CUNHA A. M- Uma Abordagem para
oDesenvolvimento de so.fhvare Cr&Leo EmbarcadoAeroespacial com
Garantia de Segurana. S. Jose~ dosCampos, In: Anais do Simp6sio
sobre Seoourana emInformatx.ca, 1999. p. 57-67.
MlNlSfRY OF DEFENSE, Safety Management Requirementsfor Defense
System. London. 1997. (Defence Standard OO-56). Dispom"vel por
rnex.o da www no endereo http`,1/www-scm.tees.ac"ukI
hazoplhtmll56.htrn.
MONTALK J. P. P. Computer sofiware in Civil Aircraft.Lond_on..
Butterworth-Heine ,mann. 1993. volume 17, no I . p.17-23.
MOURA C A, T. e SANTELLANO J. ..software AeroespaciaLno Brasil:
Um pequeno Balarxo e perspectinas para oSetor". A publx"car,
1999.
MOURA C. A. T. . SANTELLANO J. . NETO A. A- sofhvare eSeguranVa
de Sz.stemas Aeroespaciaz.s. In: Anais do encontrode Im.cia-o
Cx.endfxca e P6s Graduaa-o, Outubro de 1996,p. 166 170.
MOURA C. A. T. Uma Estraz6gia de Analise de SeguranVa desoliware
para aplicao-es Cn�tz"cas. S~ Jose" dos Campos..ITA, 1996. Tese de
Mestrado.
PARNAS D. L. Can software for the Strategz`c Defense ever
beerror free?. Computer, Novembro de 1986, p. 61 - 67.
PARNAS D. L. sofrWare Aspects of Strategic Defense
Systems.Amen'can Scientist, Setembro/Outubro de 1985, vol. 73.
p437- - 440.
PORTO L J., DE BORTOLI L. A" Sistemas Tole,antes aFalhas.
Disponx'vel por mex.o da www no
endereohttp..llwww"inf.ufgrs.brl=opesqux~sa/tflportugueslensinoll.xsangelalsegsoft.
htrnl, Julhode 1997.
PRESSMAN R. S. Engenharz.a de so.ftware. Quarta Edia-o,MaIu"on
Books, New Jersey.. 1995.
SANTELLANO J. . MOURA C. A. T. ~ LIMA A. C. cc al.Estrate~gias
de Segurana de sofiware.. A Abordagem doPadra-o MIL STO_498" A
pubh-car, 1998.
QuaTIC"2001 / 153
