Anais do XIX Congresso Brasileiro de Automática, CBA 2012.

ARQUITETURAS MOON(D) PARA PORTAS DE ENTRADA E SAÍDA DE REMOTAS

EM CONFORMIDADE COM A IEC 61508

SÉRGIO CECHIN, TAISY S. WEBER, JOÃO C. NETTO

Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS)

Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brasil
{cechin,taisy,netto}@inf.ufrgs.br

Abstract Safety functions for critical systems performed by programmable devices require certification of their safety integ-
rity. However, safety standards impose strong restrictions on the creativity of developers. The challenge is to create efficient so-
lutions in terms of cost and performance and still comply with all requirements of a given safety standard to achieve the desired
certification. This paper presents the “realization”, according the life cycle specified by the IEC 61508, of a remote input/output
subsystem to be used in safety instrumented systems applied to oil and gas extraction. It also shows the comparison of fault toler-
ant architectures aimed at high level of safety integrity that should be developed in accordance with IEC 61508.

Keywords Functional safety, safety instrumented systems, SIL, I/O, diagnostics

Resumo Funções de segurança para sistemas críticos executadas por dispositivos programáveis exigem certificação interna-
cional de integridade de segurança. Normas de segurança impõem fortes restrições à criatividade dos desenvolvedores. O desafio
é criar soluções eficientes em termos de custo e desempenho e ainda assim obedecer a todos os requisitos de uma norma para al-
cançar a certificação desejada. O artigo apresenta o projeto, de acordo com o ciclo de vida especificado na norma IEC 61508, de
uma remota de entrada e saída para ser usada em aplicações no setor de petróleo e gás em sistemas instrumentados de segurança.
Apresenta também a comparação de arquiteturas para sistemas desenvolvidos de acordo com a norma IEC 61508 para segurança
funcional e crítica visando alto nível de integridade de segurança.

Palavras-chave Segurança funcional, sistemas instrumentados de segurança, SIL, remota de entrada e saída, diagnóstico

1 Introdução põe enormes restrições à criatividade de desenvolve-

dores, mas, por outro lado, auxilia no projeto de sis-
temas capazes de alcançar a integridade de segurança
A segurança funcional na área de controle e au-
necessária e possibilita certificação internacional.
tomação de máquinas e processos é determinada por
Se o SIS é distribuído, um dos seus componentes
rígida regulamentação principalmente porque falhas
críticos é a remota de entrada e saída. O desenvolvi-
podem provocar danos irremediáveis a pessoas e ao
mento de uma remota de E/S para compor sistemas
meio ambiente (Dunn, 2003). Até o final da década
instrumentados de segurança deve iniciar pelo estudo
de 90, sistemas instrumentados de segurança (SIS)
de diferentes arquiteturas de hardware que permitam
eram, por imposição de normas e regulamentos,
alcançar a segurança almejada em conformidade com
quase exclusivamente baseados em relés, mas a pres-
a IEC 61508.
são para um melhor aproveitamento de componentes
eletrônicos programáveis se fazia sentir tanto do lado A remota de E/S é o dispositivo responsável pela
dos usuários como dos fornecedores. A norma IEC aquisição das informações dos sensores e o envio
61508 (IEC, 2010) permitiu aplicar componentes destas para um controlador lógico programável
programáveis e criou padrões para o projeto de sis- (CLP). A remota também recebe informações do
temas de segurança. CLP e faz com que sejam aplicadas aos atuadores. A
comunicação da remota com o CLP é realizada atra-
SIS são sistemas que executam funções de segu-
vés de um protocolo de comunicação seguro (Neu-
rança. Exemplos de tais funções são air-bag em au-
mann, 2007), sobre um black channel (Neumann,
tomóveis, alarme de incêndio, detecção da presença
2003). A pilha do protocolo deve ser implementada
de gases tóxicos, e sinalização de instabilidade em
tanto na remota quanto no CLP, devendo ser certifi-
plataformas marítimas de exploração de petróleo.
cada quanto à integridade de segurança por órgão
SIS construídos com componentes programáveis
internacional competente.
estão sujeitos a falhas de hardware, interferências
Para o projeto de uma remota de E/S, várias op-
externas e erros de programação que afetam sua
ções de microcontroladores (MCU) são disponíveis e
capacidade de executar a função de segurança especi-
variadas arquiteturas tolerantes a falhas podem ser
ficada. Para garantir a integridade da função de segu-
implementadas com esses componentes. Para facili-
rança nos níveis exigidos por órgãos reguladores, o
tar a escolha, nesse artigo são calculadas duas métri-
projeto do sistema deve ser conduzido com inúmeros
cas: probabilidade de falhar ao executar a função de
cuidados técnicos e administrativos, escolhendo a
segurança e a cobertura de falhas dos procedimentos
cada passo as estratégias, métodos e soluções mais
de diagnóstico e detecção que podem ser emprega-
adequados para manter a taxa de defeitos perigosos
dos. Vantagens e desvantagens de cada arquitetura
dentro dos limites especificados. A observância rígi-
são analisadas, assim como sua conformidade com a
da de normas de segurança, como a IEC 61508, im-

ISBN: 978-85-8001-069-5 4500

 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.
norma IEC 61508. O estudo é uma tarefa do Projeto
RIO-SIL, financiado pela FINEP dentro da Rede
Temática de Eletrônica Embarcada para Equipamen-
tos (Rede E3).
Esse artigo apresenta os fundamentos da norma
IEC 61508, a análise de possíveis arquiteturas segu-
ras para o projeto de uma remota de entrada e saída,
os resultados da comparação qualitativa entre tais
arquiteturas.
2 Norma para segurança funcional IEC 61508
A norma IEC 61508, publicada inicialmente no
ano 2000 (Bell, 2011), mesmo sendo considerada
extremamente restritiva pelos desenvolvedores de
hardware e software, foi a primeira a permitir a apli-
cação de sistemas eletrônicos programáveis nos sis-
temas de segurança. A norma estabelece técnicas e
medidas para evitar e controlar falhas aleatórias de
hardware e erros de projeto.
Um sistema desenvolvido criteriosamente se-
gundo a norma pode almejar certificação para um
determinado nível de integridade de segurança, SIL
(Safety Integrity Level), de 1 a 4. Sistemas com me-
nor probabilidade de apresentar defeitos residuais da
função de segurança são classificados em SIL 4 (10-9
defeitos perigosos por hora ou 10-5 defeitos sob de-
manda em baixa demanda de operação). Aumentando
uma ordem de grandeza na taxa de defeitos, diminui
de uma unidade o valor do SIL, até SIL 1. Por exem-
plo, uma função de segurança de detecção de incên-
dio que apresente, no máximo, um defeito a cada
10000 demandas, seria classificada como SIL 3.
A norma não visa disponibilidade, mas garantir
que a função de segurança esteja livre de falhas que
possam conduzir a defeitos perigosos, quando de-
mandada (Jin, 2011). Dessa forma, é natural que
empregue tolerância a falhas (Lundteigen, 2009) para
alcançar segurança funcional. Adicionalmente, caso
o sistema não possa ser mantido operacional diante
da ocorrência de falhas, como seria garantido pela
tolerância a falhas, as funções de segurança são pro-
jetadas para que suas saídas sejam comutadas para
um estado seguro, geralmente parando ou desernegi-
zando a máquina ou processo que está sendo contro-
lado ou monitorado.
A IEC 61508 teve uma grande receptividade e
vários equipamentos e componentes foram desenvol-
vidos visando permitir alcançar os níveis de integri-
dade de segurança definidos. Em 2010 a norma foi
revisada consolidando 10 anos de experiência na sua
aplicação (Bell, 2011). No meio industrial brasileiro,
entretanto, é recente o interesse pelo desenvolvimen-
to de produtos em conformidade com essa norma.
2.1 Comunicação com as remotas
Quando o sistema crítico exige controle e/ou ins-
trumentação distribuídos, as normas definem que os
sistemas de comunicação não podem ser responsá-
ISBN: 978-85-8001-069-5
veis por mais do que 1% das falhas não cobertas
pelos mecanismos de detecção e diagnóstico.
A versão original da IEC 61508 estabelecia que
todos os subsistemas de comunicação deveriam ser
igualmente seguros e certificados. Essa exigência
impunha sérias limitações ao desenvolvimento de
sistemas remotos que dependem de comunicação
entre seus componentes. A maior dificuldade era a
impossibilidade de usar protocolos de comunicação
já consolidados na área de controle e automação, mas
não certificados pela IEC 61508. Uma solução de
alto custo seria desenvolver e certificar tanto a pilha
de protocolos como os dispositivos de rede, de acor-
do com os critérios da norma, que são extremamente
restritivos.
A resposta ao problema veio com o conceito de
black channel (Neumann, 2003). Toda a pilha de
protocolos e o meio físico que transporta o sinal
elétrico, magnético ou ótico são considerados uma
caixa preta e, sobre ela, é implementado um “proto-
colo seguro”: camada que reduz a probabilidade de
erro na comunicação pela implementação de diversos
mecanismos para detecção de falhas e correção de
erros, previstos na norma. Para que o cenário esteja
completo, basta que a implementação dessa nova
camada seja certificada como segura e toda a comu-
nicação será considerada segura.
Do ponto de vista do desenvolvedor, o conceito
de black channel é extremamente confortável, pois
torna possível o uso de uma pilha convencional de
protocolos de comunicação sobre a qual basta adi-
cionar um protocolo seguro implementado em soft-
ware. Finalmente, usando essa nova pilha de protoco-
los, implementa-se o programa que executa a função
de segurança. O conceito de black channel foi o res-
ponsável pelo aparecimento de vários protocolos de
comunicação seguros, tais como PROFIsafe,
INTERBUS, OpenSafety, FOUNDATION Fieldbus
e EtherCAT (Neumann, 2007). Uma dada implemen-
tação em software desses protocolos é passível de ser
certificada segundo a IEC 61508 até o nível SIL3.
Perfis de protocolos seguros foram normatizados
pela IEC 61784-3 (Bell, 2011).
No projeto, escolheu-se o PROFIsafe (Profi-
bus_PROFIsafe, 2011) como protocolo de comuni-
cação no SIS, principalmente devido a sua populari-
dade, qualidade da documentação e a pré-aprovação
de sua especificação para SIL 3. A pré-aprovação da
especificação para SIL 3 não implica em garantias
que a implementação em software para um dado
hardware será certificada, mas facilita o processo de
certificação.
2.2 Arquiteturas sugeridas pela norma
A IEC 61508 usa a nomenclatura MooN(D) para
designar as arquiteturas de hardware do equipamento
que realiza a função de segurança e refere-se às ca-
pacidades de votação e de redundância do sistema. O
valor N indica quantos canais redundantes executam
a função de segurança, enquanto M indica quantos
4501
 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.
desses canais devem estar disponíveis. Esses valores
formam o parâmetro HFT – Hardware Fault Tole-
rance – usado pela norma para caracterizar o número
de falhas perigosas que a arquitetura suporta sem que
a função de segurança venha a apresentar defeito.
A letra D refere-se a “diagnóstico” e indica a e-
xistência de testes regulares do canal de operação
para verificar o seu correto funcionamento, e usar
estes resultados para controlar o circuito de votação
na saída, levando-o a apresentar uma saída correta ou
uma saída segura. Na ausência da letra D, os testes
são ainda usados, mas apenas para alertar a existên-
cia de falhas. Neste caso, os testes somente reportam
as falhas encontradas e não mudam o estado das
saídas.
Arquiteturas sugeridas pela norma são de um,
dois e três canais de operação, com ou sem diagnós-
tico (Lundteigein, 2009). As arquiteturas de três
canais são pouco usuais devido ao seu alto custo de
produção e manutenção. Por outro lado, a arquitetura
de um canal sem diagnóstico oferece uma baixa
segurança funcional, pois não apresenta nenhuma
redundância. Dessa forma, essa arquitetura é usada
apenas em equipamentos muito simples.
Exemplos de MooND são mostrados na figura 1.
Cada retângulo corresponde a um canal: sistema de
hardware e software capaz de executar, sozinho, a
função de segurança. A elipse menor representa o
circuito de votação, denominado aqui de votador,
uma tradução livre de voter usado na IEC 61508.
CANAL
1oo1
CANAL Votador
diagnóstico 1oo1D
CANAL
diagnóstico Votador
CANAL
1oo2
Figura 1. Exemplos de arquiteturas MooND
Uma das funções do votador (aquela que origi-
nou o nome do módulo) é escolher, dentre os valores
presentes nas suas entradas, o valor a ser colocado
em sua saída. Para isso, pode usar votação por maio-
ria ou os resultados fornecidos pelos módulos de
diagnóstico. Outra função é garantir que a saída este-
ja em um de dois estados: ou operacional e correta;
ou colocada em estado seguro. Para isso, o circuito
deve ser capaz de identificar entradas em falha ou
então decidir os valores de saída usando os resulta-
dos dos diagnósticos. Deve-se observar que cada
arquitetura demanda uma, outra ou ambas as funções
do votador. Além disso, cada combinação apresenta
ISBN: 978-85-8001-069-5
um maior ou menor grau de complexidade no seu
projeto.
3 A remota de entrada e saída
A remota de E/S, conforme mostrado na metade
direita da figura 2, é formada por uma cabeça Profi-
bus e uma interface de entrada e saída. A comunica-
ção segura da remota com a CPU ocorre através de
um canal seguro sobre PROFIBUS. O black channel
engloba as cabeças PROFIBUS que se encontram
nos dois lados da comunicação.
CPU Remota
CPU CPU Módulo
Segura Comum de E/S
PROFIBUS
Interface
Black Channel
Figura 2. Remota de E/S
A função executada pela remota é a de receber
os comandos enviados pela CPU e realizá-los, envi-
ando dados para as portas de saída ou obtendo os
dados das portas de entrada. Como a comunicação é
parte essencial da função de segurança, a remota
deve contribuir com uma baixa percentagem de erros
residuais. Para isso, os módulos que executam o
protocolo seguro, tanto na CPU como na remota,
devem ter incorporados mecanismos para detecção
de falhas e circuitos de diagnósticos com altas cober-
turas de falhas. Assim, além de executar o protocolo
de comunicação segura, a remota deve conduzir
todos os testes necessários para alcançar a cobertura
de diagnóstico e detecção de falhas especificadas
para o nível de SIL desejado.
O hardware da remota pode ser separado em
dois grupos de circuitos: um grupo dentro do black
channel e outro fora do black channel. O primeiro
grupo é “invisível” para a norma e pode ser imple-
mentado usando hardware convencional ou já dispo-
nível. Por exemplo, pode-se usar, sem preocupação
com certificação, um microcontrolador que imple-
menta o Profibus na comunicação com a CPU e E-
thercat na comunicação com os atuadores e sensores.
O segundo grupo de circuitos, fora do black
channel, que na remota corresponde ao módulo de
E/S, tem que ser construído seguindo as restrições da
IEC 61508. Para isso, deve-se escolher uma arquite-
tura NooMD adequada, a forma como o diagnóstico
deverá atuar, e implementar a cobertura de falhas
perigosas exigida para alcançar o SIL desejado.
4 Taxas de falhas
A norma divide a taxa total de falhas ( ) dos e-
lementos constituintes do sistema em falhas seguras
( ) e falhas perigosas ( ), e essas últimas em fa-
4502
 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.
lhas perigosas detectáveis ( ) e não detectáveis
( ). São consideradas falhas seguras todas aquelas
que levam naturalmente o sistema para um estado
seguro; de forma similar, todas as falhas perigosas
detectáveis pelos mecanismos de diagnóstico podem
levar o sistema para um estado seguro.
A partir dessas taxas de falhas, a norma deriva
dois parâmetros: SFF (Safe Failure Fraction), fração
de falhas seguras, DC (Diagnostic Coverage) cober-
tura de diagnóstico.
4.1. Fração de falhas seguras – SFF
Conforme descrito na norma, o SFF determina
as restrições impostas pela arquitetura à integridade
de segurança do hardware. Dessa forma, o SFF é um
parâmetro que reflete a arquitetura do sistema e serve
para compará-las, além de prever a capacidade das
mesmas em evitar que a função de segurança venha a
falhar quando demandada.
Pode-se dizer que o SFF é um parâmetro estáti-
co, característico da arquitetura. Isso fica claro quan-
do se percebe que seu valor é um percentual da taxa
total de falhas do sistema, conforme sua definição:
+∑∑
= (1)
∑
Quanto maior o SFF, menor a quantidade de fa-
lhas perigosas não detectáveis que afetam o sistema e
que podem comprometer a função de segurança. Para
reduzir as falhas perigosas não detectáveis, é neces-
sário aumentar a capacidade dos mecanismos de
detecção em identificá-las.
Considerando a definição de SFF, é de se esperar
que o SIL esteja diretamente relacionado com o SFF.
A forma como esse relacionamento é estabelecido na
norma é através de tabelas que limitam o SIL alcan-
çável pela função de segurança. Existem duas tabe-
las: uma para componentes do tipo A, onde o com-
portamento de todos os seus elementos diante de
falhas está completamente caracterizado, e do tipo B
(ou componentes complexos), onde alguns de seus
elementos não têm um comportamento bem definido,
quando sob falhas. A tabela 1 aplica-se a sistemas do
tipo B.
Tabela 1. Máximo SIL alcançável.
SFF (safe failure HFT
fraction) Tolerância a Falhas de Hardware
0 1 2
< 60 % proibido SIL 1 SIL 2
60 % - < 90 % SIL 1 SIL 2 SIL 3
90 % - < 99 % SIL 2 SIL 3 SIL 4
>= 99 % SIL 3 SIL 4 SIL 4
Na tabela 1, HFT (tolerância a falhas) refere-se à
capacidade do sistema de manter a execução da fun-
ção de segurança em caso de zero, uma ou duas fa-
lhas de hardware. Com uma arquitetura de um único
canal, nenhuma falha é tolerada; com dois canais
ISBN: 978-85-8001-069-5
pode ser tolerada uma falha; e com três canais podem
ser toleradas duas falhas simultâneas.
4.2. Cobertura de Falhas – DC
De acordo com a norma, o DC é uma estimativa
de medida de falha da função de segurança. Dessa
forma, é um parâmetro relacionado ao comportamen-
to do sistema, quando em operação da função de
segurança. Esse parâmetro serve para avaliar, estatis-
ticamente, a efetividade do diagnóstico em detectar
falhas.
Como esse parâmetro reflete o comportamento
da função de segurança, ele corresponde a um parâ-
metro dinâmico. Essa característica pode ser obser-
vada na sua definição, pois representa um percentual
das falhas perigosas:
∑
= (2)
∑
O DC caracteriza as técnicas de diagnóstico, de
tal forma que um valor elevado indica uma técnica
eficiente. A partir de seu valor, determinam-se as
taxas de falhas perigosas detectáveis e não detectá-
veis e, finalmente, pode-se calcular o SFF.
5 Análise das Arquiteturas
Tomando por base a discussão anterior, em que
foram excluídas as arquiteturas com três canais e
1oo1, escolheu-se avaliar as arquiteturas 1oo2,
1oo2D e 1001D.
5.1. Arquitetura 1oo2
Conforme apresentado na figura 3, essa arquite-
tura é formada por dois canais em paralelo de tal
forma que a função de segurança pode ser realizada
por cada um deles, individualmente. Assim, a função
de segurança só apresentará uma falha perigosa,
quando demandada, se os dois canais forem acometi-
dos por falhas perigosas. Adicionalmente, o circuito
de diagnóstico é responsável por, apenas, relatar
eventuais falhas; não é capaz de atuar no estado das
saídas dos canais ou da saída do votador.
CANAL
diagnóstico Votador
CANAL
1oo2
Figura 3. Arquitetura 1oo2
A análise dessa arquitetura deve ser conduzida
através de dois cenários. No primeiro cenário (apre-
sentado na figura 4), ocorre uma falha perigosa em
um dos canais, que é detectada pelo diagnóstico e
reparada. Desde a ocorrência da falha até o término
4503
 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.
de seu reparo, o sistema opera em modo degradado,
como se fosse uma arquitetura 1oo1.
Falha Recuperação
1oo2 1oo1
Figura 4. Arquitetura 1oo2 com 1 falha
No segundo cenário (figura 5), considera-se a
ocorrência de duas falhas, de maneira que a segunda
falha ocorra durante o período em que a primeira
ainda não foi recuperada. Com a primeira falha, a
arquitetura passa a operar de forma degradada, como
um 1oo1; quando ocorre a segunda falha, a saída do
votador será colocada em um estado não seguro e só
será recuperado quando for recuperado o primeiro
canal que falhou ou quando for executado o “proof
test”.
Falha Falha
1oo2 1oo1 Falha Perigosa
Figura 5. Arquitetura 1oo2 com 2 falhas
5.2. Arquitetura 1oo2D
Conforme apresentado na figura 6, essa arquite-
tura é bastante semelhante à 1oo2. A principal dife-
rença é que o circuito de diagnóstico também é res-
ponsável por atuar no estado da saída do votador,
podendo levá-la para um estado seguro, quando am-
bos os canais estiverem em falha perigosa.
CANAL
diagnóstico Votador
CANAL
Figura 6. Arquitetura 1oo2D
Novamente, a análise da arquitetura deve ser fei-
ta pela observação de dois cenários: o primeiro, onde
ocorre uma falha que é reparada, apresenta o mesmo
comportamento da arquitetura 1oo2, conforme figu-
ra 4.
No segundo cenário, após a segunda falha sem
que tenha acontecido o reparo da primeira, o circuito
de diagnóstico irá atuar sobre votador de maneira que
sua saída seja colocada no estado seguro. Na figura 7
é apresentada a linha de tempo desse cenário, onde
após a segunda falha o sistema é colocado no seu
estado seguro.
Essa arquitetura é equivalente à arquitetura
1oo2, enquanto ocorre uma falha. Quando ocorre a
segunda falha, a arquitetura 1oo2D leva ao estado
seguro enquanto que a 1oo2 leva a falha da função de
segurança, quando demandada.
ISBN: 978-85-8001-069-5
Falha Falha
1oo2 1oo1 Estado Seguro
tempo
1oo2
Figura 7. Arquitetura 1oo2 com 2 falhas
tempo
5.3. Arquitetura 1oo1D
Conforme apresentado na figura 8, essa arquite-
tura apresenta um único canal para realização da
função de segurança. Dessa forma, a princípio, a
função de segurança poderá falhar quando demanda-
da, se ocorrer uma falha perigosa no canal. Entretan-
to, o circuito de diagnóstico é capaz de atuar sobre a
saída do votador, de maneira semelhante ao que
acontece na arquitetura 1oo2D. Assim, quando o
circuito de diagnóstico detectar uma falha perigosa
no canal, atuará sobre o votador de maneira a colocar
a sua saída em estado seguro.
CANAL Votador
tempo
diagnóstico
Figura 8. Arquitetura 1oo1D
Essa arquitetura possui HFT=0, ou seja, não é
capaz de suportar nenhuma falha perigosa. Entretan-
to, uma vez detectada pelo circuito de diagnóstico, o
votador pode ter sua saída colocada no estado seguro.
A forma de operação da arquitetura 1oo1D asso-
ciada com uma cobertura de diagnóstico suficiente-
mente alta, pode fornecer a uma função de segurança
com SFF maior do que se fosse utilizada a arquitetu-
ra 1oo2. Além disso, pode-se antever um custo de
produção maior da arquitetura 1oo2 do que a 1oo1D.
5.4. Comparação das arquiteturas
A arquitetura 1oo2 apresenta como principais
desvantagens a falha da função de segurança, quando
ocorrerem duas falhas simultâneas, e o alto custo
relativo para implementar os dois canais.
No caso da arquitetura 1oo2D, também aparece
como desvantagem relativa o custo dos dois canais.
Entretanto, usando-se um circuito de diagnóstico
com uma alta cobertura para a detecção de falhas
perigosas, a falha da função de segurança será pouco
provável.
Finalmente, a arquitetura 1oo1D é aquela com o
menor custo, pois utiliza um único canal. Ela tam-
bém requer um circuito de diagnóstico com alta co-
bertura para garantir a baixa probabilidade de falha
da função de segurança.
Comparativamente, apesar de alta, a cobertura
necessária para atingir SIL 3 com as arquiteturas
1oo2D e 1oo1D é diferente. A arquitetura 1oo1D
possui HFT=0, que corresponde à primeira coluna da
tabela de SFF (Tabela 1), onde se observa que o SFF
necessário deve ser maior do que 99%. Por outro
4504
 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.
lado, a arquitetura 1oo2D possui HFT=1, o que cor-
responde à segunda coluna da mesma tabela, levando
a necessidade de um SFF maior do que 90%, portan-
to menos exigente do que a arquitetura 1oo1D.
No projeto, decidiu-se por descartar a arquitetura
1oo2, devido às suas desvantagens em relação às
outras duas arquiteturas. Para decidir entre as arqui-
teturas restantes, é necessário verificar a viabilidade
de suas implementações, analisando os custos de
desenvolvimento e de produto.
6 Implementação das arquiteturas
Para verificar a viabilidade de implementação
das arquiteturas propostas, faz-se necessário detalhar
seus diagramas de blocos, indicando candidatos e-
ventuais para implementar cada um destes blocos.
No estudo dos componentes necessários à im-
plementação das funções de segurança bem como na
avaliação de suas taxas de falhas (necessárias para
determinar o DC e o SFF), verificou-se que os pro-
cessadores são os de maior impacto: aqueles que
apresentam as maiores taxas de falhas. Dessa forma,
percebeu-se a necessidade de encontrar processado-
res que apresentassem a menor taxa de falhas possí-
vel ou que fossem especialmente desenvolvidos para
aplicações de segurança. Nessa última classe podem
ser encontrados processadores como os da família
HerculesTM, da Texas e os PXS da Freescale. A famí-
lia Hercules foi escolhida para nortear as decisões de
projeto, embora todos eles tenham sido desenvolvi-
dos para auxiliar no atendimento às restrições impos-
tas pela IEC 61508.
Os processadores da família HerculesTM
(TMS570LS31x/21x Hercules ARM Safety Critical
Microcontrollers) são microcontroladores do tipo
ARM que, além de apresentarem um SFF maior do
que 99%, oferecem toda a documentação necessária
para possibilitar um projeto de hardware visando
aplicações de segurança. Por exemplo, são fornecidas
informações que vão deste as taxas de falhas do
componente até o processo de desenvolvimento utili-
zado para reduzir as falhas sistemáticas (systematic
failures), em geral relacionadas com o software, e as
arquiteturas para enfrentar as falhas aleatórias (ran-
dom failures), em geral relacionadas com o hardwa-
re.
Portanto, levando-se em consideração as arquite-
turas propostas e a disponibilidade de um processa-
dor como o TMS570, decidiu-se por explorar três
possibilidades de implementação: 1oo1D, usando
TMS570; 1oo2D, usando TMS570, e 1oo2D, usando
microcontroladores comuns (MCU).
As implementações discutidas a seguir restrin-
gem-se aos processadores e os circuitos necessários
para a sua operação, de acordo com a arquitetura
considerada.
ISBN: 978-85-8001-069-5
6.1. Implementação de 1oo1D – TMS570
Para obter SIL 3 com essa arquitetura é necessá-
rio que os componentes apresentem SFF maior do
que 99%. Esse é o caso do TMS570, que implementa
uma série de técnicas que levam a um valor tão alto
de SFF.
Deve-se observar que a arquitetura 1oo1D é to-
talmente implementada no TMS570, inclusive o
votador de saída que pode ser colocado em estado
seguro, caso os circuitos de diagnóstico detectem
alguma falha.
6.2. Implementação de 1oo2D – TMS570
Nessa implementação, cada um dos canais da
arquitetura será implementado com um chip
TMS570. Além dos canais, é necessário implementar
o votador, que decidirá qual dos canais terá seu valor
de saída colocada na saída do sistema. Essa arquite-
tura pode ser vista na figura 9, onde o módulo SS é
responsável por garantir que a saída possa ser colo-
cada em um estado seguro (Safe State).
TMS570
CPU
diagnóstico
Votador SS
TMS570
diagnóstico
CPU
diagnóstico
Figura 9. Implementação da 1oo2D – TMS570
O circuito dos canais terá um SFF inerentemente
alto, devido ao uso do TMS570. Resta determinar o
SFF do votador. Sem entrar em detalhes da sua im-
plementação, pode-se antever um circuito de imple-
mentação relativamente simples e seguro, na medida
em que os canais ou estão operacionais ou suas saí-
das estão em estado seguro. Dessa forma, o votador
terá como entrada uma informação correta (e segura)
ou um estado seguro.
Com um circuito simples composto apenas de
componentes discretos (sem o uso de processadores),
o votador deve alcançar SFF de 90% (pois HFT=1).
Isso implica no uso de diagnóstico conforme estabe-
lecido na IEC61508, que envolve a detecção de fa-
lhas do tipo stuck-at, stuck-open, circuito de saída
aberto ou de alta impedância, curto circuito entre
linhas de sinal (denominadas, em conjunto, de Mode-
lo DC de falhas). Além dessas, devem ser detectados
curto circuito entre dois pinos quaisquer de um cir-
cuito integrado, oscilações e variações de frequência.
Tantas falhas a serem detectadas implicam em um
desenvolvimento mais caro, sem mencionar o custo
do próprio produto.
Apesar das vantagens dessa implementação em
relação ao uso do TMS570 na arquitetura 1oo1D,
duas desvantagens são decisivas: custo e espaço
4505
 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.
físico. A implementação de dois canais com TMS570
custa, pelo menos, o dobro do uso de um canal. Além
disso, é necessário considerar-se o custo para o de-
senvolvimento e produção do circuito do votador
externo e da sincronização dos dois canais.
O projeto visa o desenvolvimento de módulos
específicos do SIS. Dessa forma, o espaço disponível
para acomodar os circuitos já está determinado, e
oferece limitações adicionais ao projeto: o uso de
dois processadores com as dimensões do TMS570,
de um votador e os circuitos de diagnóstico, está,
praticamente, descartado. Essa solução só seria viá-
vel se não houvesse alternativas para atingir o SIL
desejado.
6.3. Implementação de 1oo2D – MCU
Esta implementação da arquitetura foi elencada
por duas razões: as dimensões do TMS570 e o uso de
HFT=1.
Conforme discutido na implementação 1oo2D-
TMS570, essas MCUs são grandes para o espaço
disponível. Então, decidiu-se avaliar a possibilidade
de usar duas MCUs, mas de tamanho menor e mais
simples. Com isso, seria minimizado o problema de
espaço e, por serem mais simples, as taxas de falhas
tenderiam a ser menores. Além disso, com um
HFT=1, passa-se a operar na segunda coluna da Ta-
bela 1, fazendo com que o SFF deva ser maior do
que 90%, o que é menos restritivo do que os 99%
necessários na arquitetura 1oo1D.
Entretanto, essa implementação requer o desen-
volvimento de outros circuitos de suporte à operação
dos processadores, circuitos esses que já fazem parte
da arquitetura interna do TMS570. Em linhas gerais,
são necessários os circuitos de diagnóstico e do vota-
dor, conforme pode ser visto na figura 10.
MCU
diagnóstico
Votador SS
diagnóstico
MCU diagnóstico
Figura 10. Implementação da 1oo2D – MCU convencionais
O circuito de diagnóstico deve ser implementado
de maneira a possibilitar SFF maior do que 90%.
Conforme IEC 61508-2, isso implica em detecção de
falhas de acordo com o modelo DC de falhas (con-
forme listado anteriormente) para dados e endereços,
alteração de informações causadas por soft-errors
(erros transientes que podem ocorrer em dispositivos
com capacidade de armazenamento de informação:
registradores, memória, linhas de transmissão, etc),
erros de execução ou codificação, modelo DC de
falhas para o cálculo de endereços, apontador de
programa e ponteiro de pilha e suas alterações devido
à soft-erros. Essa lista, na realidade, não está comple-
ta, pois foram consideradas apenas as necessidades
ISBN: 978-85-8001-069-5
de diagnóstico da MCU. Um projeto detalhado, cer-
tamente, revelaria outros circuitos que deveriam ser
monitorados, aumentando ainda mais a complexida-
de do projeto e, consequentemente, seu custo e tama-
nho.
Por fim, em uma versão mais simplificada, pode-
se assumir que os circuitos de diagnóstico são capa-
zes de sinalizar a validade das saídas para o votador,
o que permitiria utilizar-se um circuito semelhante
àquele discutido na implementação 1oo2D – TMS.
Do ponto de vista do espaço físico e levando-se
em consideração o tamanho do circuito de diagnósti-
co necessário, essa solução pode não trazer muito
ganho. Se por um lado os processadores são meno-
res, eles demandam a construção de circuitos mais
complexos de diagnóstico, o que pode levar a perda
da vantagem de se usar processadores mais simples.
6.4. Comparação das implementações
A comparação entre as implementações propos-
tas pode ser resumida na análise de três parâmetros
fundamentais: custo de desenvolvimento e do produ-
to (custo), espaço necessário para implementar o
hardware (tamanho) e nível de tolerância a falhas
(HFT).
Os parâmetros de comparação associados a cada
implementação estão apresentados na tabela 2. Na
tabela, cada arquitetura e parâmetro são qualificados
em termos relativos com as outras configurações.
Tabela 2. Comparação entre implementações
1oo1D 1oo2D 1oo2D
TMS570 TMS570 MCU
Custo baixo alto alto
Tamanho pequeno grande maior
HFT 0 1 1
Dessa forma, verifica-se que o custo da solução
1oo1D – TMS570 é menor que o das outras duas
implementações, que apresentam custos semelhantes.
No parâmetro “tamanho do circuito”, a solução
que deveria ser menor (1oo2D – MCU) termina por
ser a maior de todas. A principal causa disso é a
integração de uma quantidade considerável de circui-
tos de diagnóstico dentro do TMS570, que não exis-
tem nas MCUs convencionais e teriam que ser adi-
cionados ao tamanho. Como resultado final, a arqui-
tetura 1oo1D – TMS570 é a mais compacta.
Finalmente, as arquiteturas 1oo2 – TMS570 e
1oo2 – MCU apresentam como vantagem sobre a
1oo1D o fato de terem um nível de tolerância a fa-
lhas maior, continuando a operar mesmo quando
ocorre uma falha perigosa. Entretanto, todas as três
implementações são levadas para um estado seguro o
que, do ponto de vista da segurança, reduz a impor-
tância dessa vantagem.
O resultado das análises levou a decisão de utili-
zar a implementação 1oo1D, pois é aquela de menor
custo, menor tamanho e que será colocada no estado
seguro em caso de falha perigosa.
4506
 Anais do XIX Congresso Brasileiro de Automática, CBA 2012.
4 Conclusão
De acordo com o ciclo de vida especificado na
norma IEC 61508, na sua fase de realização de
hardware e software, o artigo apresentou o projeto da
arquitetura de hardware e software das portas de
entrada e saída de uma remota de E/S e a escolha
justificada dos componentes-chave a serem usados
na implementação. As arquiteturas e suas possíveis
implementações foram discutidas e comparadas de
maneira a se chegar naquela mais favorável ao obje-
tivo do projeto. Nessa discussão, partiu-se do princí-
pio que a comunicação, entre as portas de entrada e
saída e a lógica das funções de segurança, será feita
através do mecanismo de black channel, técnica que
simplificou significativamente o desenvolvimento e a
aplicação de sistemas seguros que requerem a comu-
nicação entre seus componentes.
À primeira vista, a análise das arquiteturas e suas
possibilidades de implementação parecem ser meros
balizadores gerais para o desenvolvimento futuro,
podendo ser alterados a qualquer momento, quando
forem identificadas inconsistências. Entretanto, no
caso de sistemas que visam à segurança funcional,
essas decisões são muito mais definitivas, devido ao
alto custo associado com o desenvolvimento (e retra-
balho, no caso de erros) que é delineado e induzido
pela norma. Esse fato levou a uma importante mu-
dança de paradigma na forma como são desenvolvi-
dos os projetos: antes de desenhar qualquer circuito
ou linha de código é necessário definir a arquitetura
que será usada no projeto de maneira que seja possí-
vel alcançar o SIL desejado. Esse enfoque, conhecido
como “top-down”, é de difícil aplicação direta devido
à quantidade de fatores que devem ser considerados:
além dos fatores funcionais comuns a qualquer sis-
tema devem ser considerados fatores adicionais rela-
cionados com os níveis de tolerância a falhas e de
segurança funcional (safety), representados na norma
pelos parâmetros HFT (nível de tolerância a falhas),
DC (cobertura de diagnóstico) e SFF (fração de de-
feitos seguros) que podem ser alcançados. O resulta-
do dessas análises levou a escolha de duas arquitetu-
ras candidatas: a 1oo1D e a 1oo2D.
Entretanto, a análise pura e simples das arquite-
turas sugeridas na norma não é suficiente. Em geral,
é necessário analisar algumas informações dos níveis
de menor abstração, onde estão expressas as restri-
ções típicas de implementação: esse fato é flagrante
quando se percebe que a arquitetura 1oo2D admite
duas implementações possíveis mas com característi-
cas bem diferentes. Foram analisadas as implementa-
ções 1oo1D (que usa o TMS570), 1oo2D-TMS570 e
1oo2D-MCU. Em particular, as restrições típicas da
implementação estão, também, relacionadas com os
requisitos do projeto RIO-SIL. Foram consideradas
restrições tais como as dimensões físicas esperadas
para cada implementação, a disponibilidade de com-
ponentes adequados a implementação de funções de
segurança e o custo de cada um desses componentes.
Também foram considerados os custos de desenvol-
vimento, que são maiores do que aqueles de um
ISBN: 978-85-8001-069-5
projeto “convencional”, onde não existem restrições
de projeto que visam à segurança funcional (safety).
O resultado das comparações leva a escolha da
arquitetura 1oo1D com processador TMS570 ou
MCU equivalente em recursos para alcançar segu-
rança funcional, uma vez que essa arquitetura oferece
o menor custo, menor dimensão física e desempenho,
no caso de falha perigosa, adequado ao SIL 3 deseja-
do.
A necessidade de análise das arquiteturas para
tolerância a falhas e segurança funcional não é novi-
dade. Formalmente, ela está presente desde que se
iniciou a normatização desse tipo de sistema. Entre-
tanto, a aplicação da norma IEC 61508 em sua última
versão de 2010 representa um novo desafio para os
desenvolvedores de sistemas intrinsecamente segu-
ros. Nessa direção, a equipe de desenvolvimento tem
enfrentado esses novos desafios, buscando o aperfei-
çoamento de suas técnicas e a adequação de suas
metodologias de projeto. Esse artigo retrata a con-
quista de um desses (novos) obstáculos.
Agradecimentos
Este trabalho foi parcialmente financiado pela Finep
– Rede E3 – Projeto RIO-SIL 01.11.0154.00.
Referências Bibliográficas
Dunn, W.R. (2003). “Designing safety-critical
computer systems”. Computer 36 (11)
(novembro): 40 - 46.
Bell, Ron. (2011). “Introduction and Revision of IEC
61508”. In Advances in Systems Safety, org.
Chris Dale e Tom Anderson, 273-291. Springer
London.
IEC (2010). International Electrotechnical Com-
mission IEC 61508, part 1 to 7; Functional
Safety of Electrical, Electronic and Programm-
able Electronic Safety-Related Systems.
http://www.iec.ch/functionalsafety.
Jin, H., M. A. Lundteigen, e M. Rausand. (2011).
“Reliability performance of safety instrumented
systems: A common approach for both low-and
high-demand mode of operation”. Reliability
Engineering & System Safety 96 (3): 365–373.
Lundteigen, Mary Ann, e Marvin Rausand. (2009).
“Architectural constraints in IEC 61508: Do they
have the intended effect?” Reliability
Engineering & System Safety 94 (2).
Neumann, P. (2003). “Virtual automation network -
reality or dream”. In Industrial Technology,
2003 IEEE International Conference on, 2:994 -
999 Vol.2.
Neumann, Peter. (2007). “Communication in
industrial automation—What is going on?”
Control Engineering Practice 15 (11)
(novembro): 1332-1347.
Profibus_PROFIsafe.
http://www.profibus.com/technology/profisafe/.
Acesso em dez. de 2011.
4507