Técnicas de IA no suporte

1. O emprego de técnicas de I.A. no suporte a administração de sistemas
operacionais
Mauro M. Mattos, MSc
1
FURB – Universidade Regional de Blumenau
Departamento de Sistemas e Computação
mattos@furb.rct-sc.br
Alejandro Martins, Dr.
Roberto C. Pacheco, Dr.
UFSC – Universidade Federal de Santa Catarina
Departamento de Engenharia de Produção e Sistemas
{ alejandro,pacheco}@eps.ufsc.br
RESUMO
Este artigo tem como objetivo apresentar as principais características dos atuais sistemas
operacionais e discutir como a aplicação de conceitos de inteligência artificial pode contribuir na
concepção de uma nova geração de sistemas operacionais.
ABSTRACT
This paper describes a basic review of today operating systems main characteristics and presents
some examples of how the use of artificial intelligence concepts can contribute on the conception of
a new generation of operating systems.
PALAVRAS-CHAVE: sistemas operacionais, inteligência artificial.
1 Introdução
A última década tem produzido um enorme avanço tecnológico em termos computacionais.
Recursos que anteriormente além de muito dispendiosos, eram encontrados em poucas e
privilegiadas instalações, hoje podem ser encontradas em desktops. Segundo [1], a indústria de
microprocessadores está em meio a uma revolução graças a uma série de recursos tais como:
reutilização de projetos, melhores práticas em engenharia de lógica digital e eficiência de
fabricação. Assim sendo é possível desenvolver projetos de hardware especializados para atender a
um largo espectro de aplicações.
A indústria de software também está vivenciando um processo evolutivo, que apesar de não tão
intenso quanto aquele de hardware, caracteriza-se por : mudanças nos paradigmas de construção de
software, de disponibilidade de recursos de hardware e software de apoio (ferramentas CASE,
ferramentas de depuração e teste, compiladores, etc.), de interfaces de comunicação homem-
máquina e de distribuição de recursos de hardware e software (através da facilidade cada vez maior
de interligação de equipamentos).
Não obstante este avanço, há uma área que tem apresentado pouca evolução perante o quadro que
foi apresentado anteriormente – a área de sistemas operacionais. Segundo Mosberger [31], "Apesar
1
Doutorando no Curso de Pós-Graduação em Eng.Produção e Sistemas da UFSC – Universidade Federal de Santa
Catarina.

2. dos avanços tecnológicos experimentados nós últimos tempos, particularmente na última década, a
estrutura fundamental dos S.O's tem permanecido invariavelmente a mesma". E ele continua: "A luz
de eventos recentes como por exemplo a popularização da internet, é razoável questionar se o
enfoque em computação (computing) é aceitável. A recente ênfase em interligação de
equipamentos (networking) pode indicar que o enfoque em comunicação (communicating) pode
logo vir a se tornar a razão de ser dos computadores."
2 A organização estrutural do núcleo dos sistemas operacionais
“Era uma vez, há não muito tempo, e todo mundo sabia o que era um sistema operacional. Era um
software complexo vendido pelo fabricante do computador, sem o qual nenhum outro programa
poderia funcionar naquele computador. Ele fazia os discos girarem, iluminava os terminais, e
geralmente mantinha registros do que o hardware estava fazendo e porque. Programas de aplicação
(do usuário) faziam solicitações para o sistema operacional executar várias funções; os usuários
raramente falavam diretamente com o OS. Hoje esses limites não estão muito claros. O surgimento
das interfaces gráficas com o usuário (GUI – Graphical User Interface), linguagens de scripts e
macros, conjuntos de aplicações que podem trocar informações de forma simplificada e
transparente, e o aumento na popularidade das redes e dados distribuídos - todos estes fatores
mesclaram as distinções tradicionais. Os ambientes de computação de hoje consistem em níveis de
hardware e software que interagem para formar um todo quase orgânico” [6].
Um Sistema Operacional pode ser definido como : uma camada de software que de forma segura,
permite a abstração e a multiplexação dos recursos físicos [41]. Os primeiros S.O's começaram a
surgir a partir da segunda geração de computadores em meados da década de 50 e início da década
de 60, mais como um produto de fatoração de rotinas de run-time comuns do que efetivamente
resultado de intenção em desenvolvê-los.
A evolução deste tipo de aplicação, passou logo a seguir pela introdução do conceito de
processamento em batch, e a seguir pelo conceito de time-sharing (CTSS 1962)[12] que culminou
com o surgimento do sistema MULTICS [14] (que pretendia suportar muitos usuários simultâneos).
Apesar de não ter sido um sucesso comercial, influenciou o desenvolvimento de vários S.O's
posteriores.
O que pode ser observado ao longo da evolução dos sistemas operacionais, é a constante busca no
sentido de identificar a estrutura adequada. Sendo uma camada de software interposta entre as
aplicações e o hardware propriamente dito sua estrutura tem um impacto fundamental na
performance e abrangência das aplicações que são construídas sobre ele [25].
Inicialmente tentou-se estruturar o sistema de forma monolítica, onde o SO consistia basicamente
de um único programa escrito como uma coleção de procedimentos. A medida em que a
complexidade do ambiente aumentou, tornou-se impossível manusear esta estrutura monolítica e
abrindo espaço para o surgimento de novas propostas. O modelo em camadas, o qual pode ser
considerado como uma generalização do anterior, é projetado como um conjunto de camadas
sobrepostas onde cada uma provê um conjunto de funções para a camada superior, e é
implementada em termos das funções providas pela camada inferior.
Segundo [29] basicamente os projetos baseados nesta estrutura apresentavam deficiências
principalmente devido ao fato de que as camadas inferiores precisavam ser genéricas (com natural
perda de performance). A estrutura hierárquica embora semelhante à estrutura anterior,
apresentava o diferencial de permitir a transposição de níveis da hierarquia funcional.Um exemplo
de utilização desta estrutura é o sistema PILOT [15]. Apesar de apresentar uma série de facilidades

3. do ponto de vista de construção do S.O., estas características permaneciam isoladas dentro do
contexto do software do S.O., não podendo ser utilizadas pelos programadores de aplicação.
A estrutura de máquinas virtuais interpôs uma nova camada de software entre o S.O. e o hardware.
Apesar de ser uma inovação estrutural uma vez que esta proposta permitia que vários S.O’s fossem
executados sobre um mesmo hardware (VM/370 – [13] e mais recentemente a máquina virtual Java)
apresentava como característica uma tendência em degradar a performance da máquina.
A estrutura em micro-kernel foi proposta em seguida, e apresentava como característica a
construção de uma pequena porção de software responsável pelo suporte a interações entre
processos que implementam serviços do S.O.. Uma variação deste enfoque denomina-se kernel
coletivos, onde o núcleo do S.O. é construído como uma coleção de processos altamente
independentes. Pode-se citar como exemplo os sistemas Chorus [19], V-Kernel[7], Mach[5] e
Amoeba [28].
Dentro desta filosofia, destaca-se também uma proposta relativamente recente denominada exo-
kernels [17] onde o enfoque principal é eliminar a noção de que um sistema operacional deve
prover abstrações sobre as quais as aplicações são construídas e suportar a multiplexação segura do
hardware. Todas as aplicações, primitivas básicas e serviços podem implementar as tradicionais
abstrações de sistemas operacionais, especializadas para cada necessidade[25].
A estrutura cliente-servidor tem surgido também ultimamente como uma forma de organizar os
módulos do sistema, permitindo a movimentação do código do S.O. para os níveis mais altos,
movendo tanto quanto possível as funções do S.O. para dentro dos processos do usuário, deixando o
kernel com um tamanho mínimo [46].
A estrutura baseada em objetos baseia a construção do S.O. utilizando o conceito de objetos, onde
os serviços do sistema são implementados como uma coleção de objetos, os quais são definidos
como segmentos protegidos, que encapsulam estados privados de informações ou dados e de um
conjunto de operações associadas, através dos quais os estados internos são acessados e alterados
[46]. Exemplos destes sistemas são Hydra[42], chorus [3], amoeba [28].
As estruturas reflexivas caracterizam-se como sistemas capazes de acessar sua própria descrição e
alterá-la de modo a alterar seu próprio comportamento. Estas estruturas apontam para uma nova
forma de construir-se aplicações tanto a nível de sistema operacional quanto a nível de programas
de aplicação, apesar dos esforços ainda em sua maioria serem em ambiente de pesquisa acadêmica.
Pode-se citar como exemplo o sistema Apertos [43].
E finalmente, as estruturas baseadas em conhecimento (também em nível de pesquisa) tem como
elemento básico do modelo uma base de conhecimento, a partir da qual propõe-se a criação de um
suporte mais inteligente para as aplicações e melhores ambientes para o usuário. O sistema Cosmos
[30] representa um exemplo de implementação baseada neste modelo, onde todos os recursos são
representados como abstração do modelo de objetos, incluindo o kernel do sistema[46].
3 A evolução na área de Sistemas Operacionais
Analisando-se este processo evolutivo pode-se constatar que, a afirmação anteriormente
apresentada de que a área de sistemas operacionais não tem apresentado uma evolução compatível
com a tecnologia disponível. Isto pode ser analisado tanto em termos de sistemas operacionais de
propósitos específicos (RTOS – Real-Time Operating Systems) quanto em termos de sistemas
operacionais de propósitos gerais (Windows, Unix, etc.). Segundo [45], com a disponibilidade de

4. mais de 80 sistemas operacionais de tempo-real (RTOS) no mercado, pode parecer estranho que
ainda assim haja a necessidade de desenvolver-se soluções caseiras para aplicações específicas. “No
passado, esta solução devia-se diretamente a natureza monolítica das soluções comerciais. Hoje,
apesar de haverem soluções interessantes para nichos de mercado específicos, ainda há pouca
versatilidade nas soluções no que tange a capacidade de crescimento e adaptação além daqueles
nichos”.
A categoria de software acima citada refere-se aos sistemas operacionais de tempo-real, cujos
investimentos estão sendo realizados no sentido de atender aos requisitos de novos produtos de
software ditos embutidos tais como: telefones celulares, pagers, videocassetes, PDA’s (Personal
Digital Assists) e outros tantos equipamentos eletrônicos que apresentam alguma capacidade de
processamento de informações.
Seguindo o mesmo raciocínio, mas agora voltando-se para os sistemas operacionais de propósitos
gerais, [26] afirma que, os S.O’s. atuais não são projetados para adaptar-se rapidamente a mudanças
ambientais tais como: upgrades de software e hardware e, flutuações na carga de CPU e banda de
rede disponível. Não há um mecanismo que permita a inserção de componentes auto-adaptáveis que
possam otimizar a performance do sistema de acordo com as diversidade acima comentadas.
Algumas das suposições, que segundo os projetistas do sistema operacional BEOS [4] , fazem com
que os Sistemas Operacionais atuais apresentem tais deficiências, são:
• Modelo monoprocessador: a arquitetura dos PC’s atuais foi projetada cerca de duas décadas atrás, em
uma época onde o custo dos microprocessadores era alto; hoje eles são considerados commodities. No
entanto, ainda são usados S.O’s que podem ser executados em somente um processador;
• Tratamento de mídia digital: muitas das necessidades requeridas hoje em termos de mídia digital
(imagens, sons, internet e outros) eram talvez consideradas em teoria quando os atuais S.O’s foram
projetados. O resultado disto é que faz-se necessário adaptar-se novas partes de funcionalidade a atual
arquitetura, a qual não consegue tratá-las adequadamente, ou seja, a indústria está tentando liberar
soluções para a próxima década usando arquiteturas projetadas para resolver problemas da década
passada;
• Compatibilidade: a cada ano, os avanços de hardware melhoram significativamente a velocidade (e
reduzem custos) dos processadores e periféricos. No entanto, o usuário final somente percebe uma fração
dos recursos liberados a cada nova versão de hardware em função da retro-compatibilidade binária;
Neste contexto, [21] comenta que o crescimento da Internet tem permitido um nível de
conectividade entre computadores que atinge um nível de onipresença. Mas, este progresso tem
gerado um determinado número de problemas que não são adequadamente tratados pelos atuais
Sistemas Operacionais disponíveis. São eles:
• Utilização de um grupo de máquinas para execução de computação distribuída;
• Migração de dados, computação e usuários;
• Manutenção e atualização de software, dependências entre componentes e portabilidade;
• Escalabilidade e confiabilidade de sistemas e software;
• Administração distribuída do sistema
• Segurança.
Visando superar estes problemas, diversas soluções em termos arquitetônicos tem sido propostas
para ambos os tipos de aplicações de sistemas operacionais. Vale citar as propostas : EPOC [17],
FLUX [18], SLK [37], Itron [14] e ECOS [16] para a área de RTOS ; bem como as propostas: 2K
[19, 2]; Scout [25] , BEOS[4], Maruti [23] e SPIN [39] para a área de S.O’s de propósitos gerais.

5. 4 Características principais dos atuais Sistemas Operacionais
Apesar de finalidades aparentemente diferentes, todas as propostas recaem sobre a definição
apresentada inicialmente, ou seja: um componente de software que controla o hardware e o torna
disponível ao usuário. E neste sentido apresentam (entre outras) as seguintes características:
• Suporte a primitivas de sincronização e intercomunicação de processos (threads);
• Suporte a um ou mais algoritmos de escalonamento (mono,multiprocessador);
• Suporte a uma ou mais estratégias de gerenciamento de memória;
• Suporte a tratamento de exceções;
• Suporte a multiprocessamento (simétrico ou não);
• Suporte a gerência de meios de armazenamento;
• Facilidades de intercomunicação e interligação;
• Interfaces mais amigáveis com o usuário
Conclui-se portanto que, o enfoque adotado até o momento mantém-se fiel a definição apresentada
anteriormente e, dessa forma, não se vislumbra a curto prazo o emprego de técnicas de inteligência
artificial (IA) na concepção de uma nova arquitetura de sistema operacional ( a nível comercial )
que seja mais adaptável as necessidades do usuário. Dentro deste enfoque, a seção seguinte discute
o uso de técnicas de I.A. como ferramentas de suporte a construção de uma nova geração de
sistemas operacionais.
5 O uso de técnicas de I.A. em sistemas operacionais
“Os últimos anos tem estabelecido o início de uma nova era para sistemas operacionais. A
computação distribuída é certamente uma dimensão deste contexto. Nós afirmamos contudo que,
aspectos qualitativos serão uma segunda dimensão maior ainda. Estas mudanças causarão profundos
efeitos no projeto de sistemas operacionais.” [30].
Considerando-se esta afirmação (de 1989) e que embora Fleisch [Fle83] tenha sugerido em 1983,
que a inteligência deveria um elemento chave no projeto dos futuros sistemas operacionais pode-se
verificar realmente que há um atraso significativo em termos do uso efetivo na área de
desenvolvimento de sistemas operacionais, das várias ferramentas tecnológicas desenvolvidas ao
longo deste período. A medida em que cada vez mais recursos foram disponibilizados aos usuários,
uma demanda cada vez mais crescente por qualidade de serviço vem superando a capacidade dos
desenvolvedores de sistemas operacionais em prover soluções adequadas.
É opinião dos autores que, o uso de técnicas de inteligência artificial (amplamente utilizadas nas
mais variadas áreas de aplicação) poderiam contribuir significativamente para o aumento da
qualidade de serviço fornecido pelos sistemas operacionais. A seguir apresenta-se a título de
ilustração, exemplos de aplicação de 3 dos conceitos de I.A., que poderiam ser integrados no
projeto de uma nova concepção de S.O.. São eles: lógica difusa, sistemas especialistas e redes
neuronais.
5.1 O conceito de vago
A linguagem humana pode ser caracterizada pelo uso corriqueiro de termos cuja tradução em
termos precisos não ocorre sem alguma perda semântica. Na área de sistemas operacionais em
particular, pode-se constatar esta afirmação, através da avaliação que normalmente se realiza sobre
o nível de performance dos equipamentos em determinado momento - "a máquina esta lenta", ou "a
máquina está afundando".

6. Embora seja muito difícil traduzir estas afirmações em termos percentuais (por exemplo), as
pessoas entendem muito bem o significado das afirmações.
A atividade de administração de um sistema operacional é uma tarefa árdua, complexa e muitas
vezes uma questão “vaga” e que depende da experiência de alguns chamados “gurus”. Esta
afirmação pode ser considerada como uma verdade irrefutável para praticamente todos os sistemas
operacionais que já surgiram no passado e vale inclusive para aqueles mais “modernos” que
possuem uma interface com o usuário mais agradável. Mais cedo ou mais tarde os seus segredos
necessitarão ser devidamente ajustados por um profissional mais experiente para garantir um
perfeito funcionamento (ou pelo menos próximo disto).
Apesar da grande quantidade de manuais e livros disponíveis tratando do assunto, esta atividade
requer um nível de especialização bastante elevado, além de constantes atualizações tendo em vista
que a cada momento novas versões são disponibilizadas incorporando novas facilidades e/ou
corrigindo problemas (que por sua vez incorporam novo comportamento ao sistema ) o que conduz
a um círculo vicioso e desgastante.
Não obstante a documentação descrever o que significam os parâmetros dos comandos, e os
resultados esperados, há poucas referências sobre a análise que deve ser feita sobre os dados
resultantes. E na verdade, esta informação não é disponibilizada porque depende de vários fatores
inter-relacionados tais como:
• Configuração do hardware em questão;
• Configuração atual do sistema operacional para operar com o hardware em questão;
• Carga do sistema em função do número de usuários ativos em determinado momento e,
• Característica das aplicações que estão em execução em determinado momento.
Dentro deste contexto, a técnica que possibilita uma tradução de valores numéricos para termos
vagos com uma precisão mais adequada, é denominada : lógica difusa. A seguir são apresentados os
conceitos mais comuns desta proposta.
5.2 Conceitos de lógica difusa
O enfoque dos sistemas de lógica difusa é voltado para produtos e soluções que incorporam a
capacidade humana de distinguir os conceitos imprecisos e tratar incertezas oriundas de
informações parciais ou incompletas [34]. Assim sendo, lógica difusa, por definição[44,45], é um
ramo da lógica que utiliza graus de pertinência em conjuntos ao invés de utilizar uma referência de
pertinência estritamente verdadeira ou falsa. Ou seja, a idéia básica é que os valores que
representam verdades são representados dentro do intervalo entre [0.0 , 1.0], sendo que o valor 0.0
representa o valor lógico absolutamente falso e, o valor 1.0 representa o valor lógico absolutamente
verdadeiro.
Neste contexto, pode-se verificar que, a seguinte afirmação: "o sistema está muito pesado" poderia
ser traduzido para um valor de pertinência de 0.8, o que denotaria um condição de baixa
performance. Neste exemplo, "muito pesado" caracteriza um valor típico de uma variável
lingüística, ou seja, em lógica difusa, permite-se que valores dos atributos que descrevem uma
determinada situação, possuam valores "vagos" (neste caso valores típicos para uma variável
lingüística performance poderiam ser: leve, moderado, pesado, muito pesado, afundando).
A lógica difusa atribui valores a um evento com base na função de pertinência definida como:
µA(x) : X→ [0,1], ou seja, um conjunto difuso generaliza o conceito de pertinência através do uso

7. da função µ a qual retorna um valor entre 0 e 1, o que representa o grau de pertinência que um
elemento possui em relação ao conjunto A em questão.
Abstratamente, um sistema operacional poderia ser definido da seguinte forma [22]:
• Um conjunto S = {s1,s2,..,sn} onde si ∈
∈ {processo i, arquivo i, etc.} para i = 1,2,..., n . e
• Um conjunto H = {h1,h2,...,hm} onde hj ∈
∈ {computador j, dispositivo de IO j, páginaj, setor de discoj,
etc.} para j = 1,2,..., m.
Em situações de incerteza, estes conjuntos tradicionais não conseguem representar o atual
comportamento de seus elementos. Assim sendo, eles podem ser transformados em conjuntos
difusos conforme apresentado a seguir:
• Um conjunto Sf = {[s1,µ
µ(s1)], [s2,µ
µ(s2)],.., [sn,µ
µ(sn)]} onde si ∈
∈ {processo i, arquivo i, etc.} para i = {1,2,...,
n }, e
• Um conjunto Hf = {[h1,µ
µ(h1)], [h2,µ
µ(h2)],.., [hn,µ
µ(hn)]} onde hj ∈
∈ {computador j, dispositivo de IO j,
páginaj, setor de discoj, etc.} para j = {1,2,..., m}.
• µé a função de pertinência do conjunto Sf ou Hf e µ
→ [0,1].
É possível ainda, a definição de múltiplos conjuntos difusos no mesmo universo de discurso, o que
possibilita que um mesmo elemento possa vir a ser considerado como membro parcial em mais de
um conjunto difuso. A figura 1 apresenta a definição de múltiplos conjuntos para a variável
lingüística: taxa de trocas de contexto (context switching), e foi obtida através de várias amostragens
realizadas nos laboratórios da FURB (em equipamentos IBM RS-6000 rodando sistema operacional
AIX). A partir da fundamentação anteriormente apresentada, os conjuntos difusos que representam
a situação apresentada na figura 1a poderiam ser descritos como apresentado na figura 1b.
Kandel [22] sugere que técnica de inferência difusa pode ser aplicada nas seguintes situações:
seleção de um algoritmo de escalonamento útil, avaliação da performance geral ou avaliação de
performance de algum módulo em particular . Em seu trabalho, são descritos mais detalhadamente a
aplicação dos conceitos difusos em gerenciamento de processos, gerenciamento de estratégias de
armazenamento e gerenciamento de arquivos.
A questão que surge neste momento é: E como fica a performance do sistema considerando-se que a
troca de contexto ocorre em intervalos muito pequenos (da ordem de milisegundos) e certamente o
processo de fuzificação, inferência e defuzificação deve consumir uma parcela significativa de
processamento? Em função da atual arquitetura de hardware, provavelmente este procedimento
somente poderia ser executado através de um hardware coprocessador difuso (seção 6.1.1), o qual
receberia informações do sistema operacional e retornaria o identificador do próximo processo a ser
Figura 1 –(a) Múltiplos conjuntos difusos para a variável lingüística: taxa de trocas de contexto;
(b) conjuntos difusos
Conjuntos Difusos
MA= { (960,0), (680,1), (570,0) }
A = { (660,0), (560,1), (410,1), (330,0)}
M= { (370,0), (260,1), (160,1), (60,0) }
B = { (200,0), (80,1), (15,0) }
MB= { (120,0), (45,1)}
Legenda:
MA : muito alto A: alto
M: médio B: baixo
MB: muito baixo
(b)
C o n j u n t o s d i f u s o s p / N o . T r o c a d e C o n t e x t o
0 , 0 0
0 , 2 0
0 , 4 0
0 , 6 0
0 , 8 0
1 , 0 0
1 , 2 0
850
750
650
550
450
350
250
150
50
grau
de
pertinência
1 , 0 0 m u i t o a l t o
0 , 7 5 a l t o
0,50 medio
0 , 2 5 b a i x o
0 , 0 0 m u i t o b a i x o

8. escalonado, caso contrário, o sistema certamente apresentaria um nível de degradação bastante
acentuado. Esta questão será discutida a seguir.
5.3 Suporte de hardware difuso
Segundo [35], três décadas de sistemas baseados em lógica difusa conduziram ao desenvolvimento
da primeira geração de hardware baseado em lógica difusa, cujo principal objetivo foi o de obter
soluções de controle difuso mais rápidas. Até recentemente, a maioria destas soluções eram
implementadas como módulos de software, executando sobre microprocessadores convencionais,
computadores pessoais ou estações de trabalho (workstations).
No entanto a aplicação destas soluções em ambientes com requisitos de tempo-real , orientaram as
pesquisas no sentido do desenvolvimento hardware baseado em lógica difusa. Num primeiro
momento a solução emergiu em uma forma de implementação em chips, de uma máquina de
inferência difusa incorporando controladores difusos baseados em regras. Assim criou-se uma
impressão de que a única aplicação desta tecnologia seria para aparelhos domésticos e produtos de
consumo.
Contudo a necessidade de soluções para a área de processamento de informação, tais como:
construção, simulação e modelagem de aplicações, recuperação de informações em bases de dados
e outras aplicações semelhantes , estão conduzindo as pesquisas em direção ao desenvolvimento de
microprocessadores com suporte a software e dispositivos periféricos [35].
Segundo [35], as primeiras tentativas em estudar sistemas de chaveamento em lógica difusa e sua
implementação eletrônica resultaram no desenvolvimento de um componente flip-flop. A partir daí,
seguiram-se várias implementações de hardware de processamento de inferência difusa que
demonstraram aplicações de controle com vários níveis de inferência difusa. Surgiu então a medida
FLIPS – Fuzzy Logic Inferences Per Second que é análoga aquela usada para os processadores
tradicionais (MIPS – Million Instructions Per Second).
Patki [33] complementa que, a maioria dos trabalhos baseadas em hardware difuso descritos na
literatura descreve as soluções como módulos em hardware que suportam o mapeamento de
conjuntos difusos em conjuntos difusos através de um módulo fuzificador, uma máquina de
inferência e um módulo defuzificador. Estes módulos são integrados na forma de ASIC's
(Application Specific Integrated Circuit).
Em função das limitações deste enfoque, as soluções em hardware para controle difusos passaram a
ser abordadas através de um enfoque arquitetônico, o que originou os seguintes segmentos de
pesquisa: coprocessadores fuzzy dedicados; ASIC's de inferência difusa e, a construção de
conjuntos de instruções (chip set) difusas genéricos. Este último enfoque tem a finalidade de
preencher o espaço entre as duas propostas anteriores.
Portanto, aquela visão inicial de que sistemas de lógica difusa constituíam-se em soluções
especializadas em software está mudando. Segundo [33] espera-se que todo um novo espectro de
aplicações venha a emergir onde até o momento era considerado impraticável dado as limitações
das técnicas convencionais baseadas em lógica booleana e, novos chip sets venham a ser projetados
especificamente adaptados para suportar operações envolvendo lógica difusa.
Como referido anteriormente, os esforços atualmente na área de hardware difuso estão mudando no
sentido do desenvolvimento de um microprocessador com sua própria Unidade de Lógica e

9. Aritmética Difusa para uso nas mais variadas aplicações. Este enfoque está abrindo um novo campo
de pesquisas que deverá cobrir os seguintes aspectos [33]:
• Arquitetura de um conjunto de instruções (instruction set) para processamento de informações difusas;
• Construção de uma unidade lógica e aritmética difusa, como uma unidade funcional;
• Estudos de precisão relacionados a representação de conjuntos difusos e seus respectivos graus de
pertinência (membership);
Portanto, analisando-se a tendência acima descrita, a partir do momento em que novas arquiteturas
de processadores (incorporando os conceitos de lógica difusa e redes neuronais ) venham a ser
disponibilizadas, um grande espectro de novas aplicações deverá surgir, e naturalmente, novas
gerações de sistemas operacionais deverão ser construídas para suportar esta evolução
5.4 Uso de sistemas especialistas
Uma iniciativa que deve ser citada e que usa conceitos de I.A. sobre a arquitetura de sistema
operacional tradicional (UNIX) , refere-se ao trabalho de Cockcroft [8,9,10,11], o qual construiu um
sistema especialista que, apesar de não incluir regras difusas, apresenta os resultados do estado dos
vários componentes do sistema sendo monitorado, através de uma notação de cores que facilmente
poderia ser portada para conjuntos difusos. A notação é a seguinte:
• Estado branco: indica que o recurso não está sendo utilizado;
• Estado azul: indica que o recurso está desbalanceado;
• Estado verde: indica estado de operação normal;
• Estado âmbar: indica condição de atenção;
• Estado vermelho: indica sobrecarga ou detecção de algum problema;
• Estado preto: indica problema.
Através desta interface, o usuário pode mais facilmente mapear intuitivamente o estado do sistema
operacional, sem ter que aprofundar-se em estudos de valores numéricos. Uma questão a ser
destacada refere-se ao fato de que, esta solução vale somente para sistemas Solaris, e vale-se da
experiência do autor na criação da base de regras. Apesar desta base estar disponível para
download, há pouca documentação auxiliar que facilite o ajustes dos percentuais adotados pelo
autor quando da criação das mesmas, ou seja, um usuário sem a experiência do autor poderia alterar
as regras de forma que mesmo com problemas o sistema poderia reportar situação normal.
5.5 O uso de redes neuronais
[47] em seu trabalho apresenta uma solução para o problema de escalonamento dinâmico de
ambientes multiprocessador baseado na técnica de redes neuronais. Segundo o autor, a categoria de
escalonadores adaptativos são aqueles que ajustam-se a realidade de acordo com a história recente
e/ou ao comportamento do sistema. Para tanto, o uso de redes neuronais com aprendizado
adaptativo apresentou resultados interessantes em termos de simulação.
A indicação do autor é de que sua pesquisa continuará no sentido de explorar o paralelismo inerente
na estrutura do sistema de aprendizagem, bem como no uso de outras técnicas não ortodoxas que
também podem apresentar bons resultados, tais como: algoritmos genéticos e lógica difusa.
Como pode-se observar, apesar de ser um projeto de pesquisa, ele demonstra que, a partir do
momento em que houver suporte de co-processamento (difuso, neuronal ou genético), a aplicação

10. da técnica passa a ser um recurso em potencial a ser utilizado na construção de sistemas
operacionais.
6 Comentários
Um outro aspecto que esta começando a ser abordado com maior ênfase na literatura, e que
certamente apresentará um grande impacto na forma com que os computadores são usados, refere-
se a aplicação de inferência difusa em interfaces com o usuário, não só em termos de gerenciamento
de arquivos como referido em [15], mas no sentido de incorporar facilidades de respostas do
sistema para o usuário em termos de variáveis lingüísticas e não como é realizado atualmente na
forma de mensagens curtas e códigos de erros. Esta forma de analisar-se um sistema operacional
conduz a uma nova maneira de pensar e de projetar os novos sistemas operacionais com vistas a
suportar a nova gama de aplicações que devem surgir a partir da disponibilização cada vez maior de
recursos multimídia e a partir do uso cada vez maior de outros meios de interação que não aqueles
tradicionais: mouse e teclado.
Segundo projeções baseadas em vários estudos realizados por Patki [32,33,34,35,36] o enfoque
convencional de arquitetura de hardware (Von Neumann/ Processamento paralelo) bem como dos
sistemas operacionais e softwares aplicativos não serão suficientes para atender as necessidades de
tecnologia de informações no contexto de prover informações para as grandes massas. Isto porque,
ao contrário da visão de sistema que é atualmente utilizada, os sistemas futuros a ser
disponibilizados para as grandes massas necessitarão apresentar, entre outras, as seguintes
características:
• capacidades de tratar informações parciais e/ou imprecisas e de extração de conceitos;
• raciocínio aproximado e aprendizado;
• facilidades de uso para usuários sem background em computadores;
• facilidades para usuários especializados aumentar as bibliotecas do sistema sem comprometer os
aspectos de confiabilidade e segurança;
• capacidade de auto-diagnóstico do sistema para facilitar atividades de administração e interação;
• sistema de arquivos com características não limitantes (como atualmente);
• reconhecimento da freqüência de uso de comandos durante o ciclo de vida de uma aplicação;
7 Conclusões
Através desta investigação, pode-se concluir que, a área de sistemas operacionais deverá sofrer
alterações significativas nos próximos anos tendo em vista adequar-se a nova realidade que se
apresenta. Nesta nova realidade os sistemas operacionais terão um papel importante como
componente essencial e como extensão do hardware para permitir a construção de sistemas
inteligentes.
Além disso, a tendência indica uma utilização cada vez maior no sentido de incorporar-se conceitos
da área de inteligência artificial de um modo geral, nas várias etapas que compõe a arquitetura de
um sistema operacional, de forma a torná-lo mais amigável e fazer com que ele efetivamente
assuma um papel de administrador de recursos no sentido mais amplo da palavra facilitando não só
a utilização dos equipamentos através de interfaces mais amigáveis, mas também auxiliando na
solução de problemas que o que hoje constitui-se um desafio.
8 Referências Bibliográficas
[1] Ahmed,O. The Application-specific Operating System. Computer Design, pp78, Oct 1998.
[2] Ballesteros,F.J. Hess,C.K.,Kon,F. and Campbell,R.H. The Design and Implementation of the Off++ and
vOff++ µkernels. Report UIUCDCS-R-99-2086,UILU-ENG-99-1707.University of Illinois at Urbana-
Champaign. March 1999.

11. Champaign. March 1999.
[3] BANINO,J.S. Distributed Couple Actors: A CHORUS Proposal for Reliability, IEEE 3rd International
Conference on Distributed Computing Systems, 1985.
[4] BEOS in http://www.be.com, 1998.
[5] BLACK, A. et al. Mach and Matchmaker - Kernel and Language Support for Object-Oriented Distributed
Systems. OOPSLA’86. v.21, 1986.
[6] Burk,R and Horvath,D.B. UNIX Unleashed, System Administrator's Edition. Sams Publishing, 1997.
[7] CHERITON,F.R. et al. “The V-Kernel: A software Base for Distributed Systems”, IEEE Software, v.1, n.2, p
19-43, 1984.
[8] Cockcroft,A. Virtual_adrian.se. www.sun.com/951001/columns/adrian/column2.html, Oct 1995.
[9] Cockcroft,A.New release of the SE Performance Toolkit.
www.sun.com/960301/columns/adrian/column7.html, Mar 95
[10] Cockcroft,A. SE Toolkit FAQ. www.sunworld.com/swol-01-1998/swol-01-perf.html, Jan98.
[11] Cockcroft,A. Upgrades for SyMON and SE. www.sunworld.com/swol-02-1999/swol-02-perf.html,Feb99.
[12] Corbató,F.J.,Merwin-Daggett,M.,Daley,R.C. An experimental time-sharing system. In Proceedings of the
AFIPS Spring Joint Computer Conference, pp 335-344, May 1962.
[13] CREASY,R.J. The Origin of the VM/370 Time-Sharing Systems, IBM Journal of Research and
Development, v.25, n.5, p.483-490, 1981.
[14] Daley,R.C.,Dennis,J.B. Virtual memory, processes, and sharing in MULTICS. Communications of the
ACM, 11(5):306-312, May 1968.
[15] DALAL, Y.K. et al. Pilot: An Operating System for a Personal Computer, Communication of the ACM, v.23,
n.2, 1980.
[16] ECOS: Embedded Cygnus Operating System. sourceware.cygnus.com, 1999.
[17] Epoc. Sumary of EPOC Architecture. www.symbian.com/epoc/about/aboute32.html. 1999.
[18] The Flux Research Group. www.cs.utah.edu/projects/flux/index.html. 1999.
[19] HERRMANN, F. et al. Chorus distributed operating system. Computing Systems, v.1(4), p.305-367, 88.
[20] Hydari,M.Z. Design of the 2k Naming Service. Thesis, University of Illinois at Urbana-Champaing, 1999.
[21] Itron home page. tron.um.u-tokyo.ac.jp/TRON/ITRON/home-e.html. 1998.
[22] Kandel,A.,Zhang,YQ, Henne,M. On use of fuzzy logic technology in operating systems. Fuzzy Sets and
Systems 99, Elsevier Science, pp 241-251, 1998.
[23] Maruti. www.cs.umd.edu/projects/maruti/index.html. 1999.
[24] Mit Exokernel Operating System. www.pdos.lcs.mit.edu/exo.html. Mar 1998.
[25] Montz, A. B., Mosberger, D., O'Malley, S. W., Peterson, L. L. , Proebsting. T. A. Scout: A Communications-
Oriented Operating System. Hot OS, May 1995.
[26] Moore,R.B. An Extensible Architecture for Distributed Object System Interoperability. Masters Thesis,
Department of Computer Science, University of Illinois at Urbana-Champaign, Aug 1998.
[27] Mosberger,D. Scout: a Path-based Operating System. Doctoral Thesis. University of Arizona, 1997.
[28] MULLENDER, S. J. et al. Amoeba - A Distributed Operating System for the 1990s. IEEE Computers.
v.23, p.44-53, 1990.
[29] NICOL,J.Operating System Design: Towards a Holistic Approach,Operating System Review. v.21, n.1, 87.
[30] NICOL, J.R, et al. Cosmos: An Architecture For a Distributed Programming Environment. Computer
Communications, v.12, n.3, p.147-157, 1989.
[31] NIST. Research and Development for the National Information Infrastructure: Technical Challenges. NIST,
Gaithersburg, MD, March 1994.
[32] Patki,A.B.,Fuzzy Systems: Technology Mission Approach. Technical Report – DE/NMC/93/5, May 1993.
[33] Patki A.B., Raghunathan G.V.- Trends in Fuzzy Logic Hardware , WSC1, Proceedings of the First On-line
Workshop On Soft Computing, Nagoya, Japan, August 19-30, 1996, pp. 180-185
[34] Patki,A.B. Raghunathan, G.V. On Datatypes for Object Oriented Methodology for Fuzzy Software
Development, WSC1, Proceedings of the First On-line Workshop On Soft Computing, Nagoya, Japan,
August 19-30, 1996, pp. 163-167.
[35] Patki A.B.- Fuzzy Logic Based Hardware: Some Experiences, Proceedings of First International Discourse
on Fuzzy Logic And The Management of Complexity FLAMOC'96, January, 15-18, 1996, Sydney,
Australia, Vol.3, pp 247-251
[36] Patki,A.B. Exploration of Developmental Trends in Java. Technology, Electronics Information & Planning,
December 1997, Vol.25, No.3, pp.125-133
[37] SLk:The Safe Language Kernel Project. www.cs.cornell.edu/slk/index.html. 1998.
[38] Spatscheck,O.,Peterson,L.L. Escort: A Path-Based OS Security Architecture. Technical Report TR97-17,
Department of Computer Science, University of Arizona ,November 1997.
[39] Spin. The SPIN Operating System. www.cs.washington.edu. 1999.
[40] Tannenbaum,A.S. Operating Systems: Design and Implementation. Prentice-Hall, 1987.
[41] Varhol,P. Real-time Operating Systems Go Modular. Computer Design, pp77-80, Oct 1998.
[42] WULF, W.A .et al.: HYDRA: The Kernel of a Multiprocessor Operating System, Communications of the
ACM, v.17, p.337-345, 1974.
[43] YOKOTE, YASUHITO. The Apertos Reflective Operating System: The Concept and Its Implementation.
Technical Report. Local de publicação: Sony Computer Science laboratory Inc., 1992.
[44] Zadeh,L.A., Yager,R.R. Fuzzy Sets, Neural Networks, and Soft Computing. VNR, New York, 1994.

12. [45] Zadeh,L.A., Kacprzyk,J.Fuzzy Logic for the Management of Uncertainty. John Wiley & Sons, New York, 92
[46] ZANCANELLA,L.C.; NAVAUX, P.O.A. AURORA:Um Sistema Operacional Orientado a Objetos para
Arquiteturas Multiprocessadoras.Anais XX SBAC-PAD,XIII Congresso da SBC,Florianópolis, 1993.
[47] Zomaya,A.Y.,Clements,M. and Olariu,S. A framework for reinforcement-based scheduling in parallel
processor systems. IEEE transactions on parallel and distributed systems. V9, N3,p249-260,Mar 1998.