Trade-off em sistemas embarcados

Comunicação incorporada.
Universidade Carnegie Mellon.
18-849b Sistemas encaixáveis ​​confiáveis.
Autor: Leo Rollins.
A comunicação é essencial para alcançar um sistema integrado e confiável distribuído. Os designers desses sistemas enfrentam vários desafios ao especificar a rede de comunicação. Os sistemas complexos normalmente requerem algum tipo de rede de mídia compartilhada. Neste ambiente, o designer deve reconhecer o trade-off fundamental que existe entre a eficiência ea previsibilidade da rede. Dado esse trade-off, o designer deve avaliar e selecionar a rede de comunicação. Deve ser dada especial atenção aos protocolos, que determinam grande parte do comportamento da rede. Finalmente, muitos métodos de detecção de erros estão disponíveis, o que é necessário para construir um sistema de comunicação confiável.
Tópicos relacionados:
A maioria dos sistemas de comunicação históricos podem ser considerados como "embutidos" pelo menos de uma perspectiva: eles têm uma tarefa muito restrita. Eles não são projetados para comunicação de propósito geral. Por exemplo, os telefones foram concebidos apenas para fins de transmissão de voz. No entanto, esse fato vem mudando nos últimos anos com o design de redes integradas de serviços. Essas redes são projetadas para transportar diferentes tipos de comunicação, incluindo sinais de voz, dados e vídeo. Mesmo os sistemas com um único propósito original, como a telefonia, foram explorados para a transferência de outro tráfego, como a transferência de dados para computadores. Outro desenvolvimento que tem interesse crescente na comunicação de propósito geral é a internet. Uma vez que os computadores em todo o mundo começaram a ser conectados, o problema das redes incompatíveis tornou-se aparente. O modelo de referência OSI (Open Systems Interconnection) foi desenvolvido na tentativa de resolver esse problema de compatibilidade. Este modelo divide o sistema de comunicação em sete camadas que fornecem diferentes níveis de serviço. As camadas foram destinadas a fornecer interfaces e serviços padrão, de modo que vários protocolos, máquinas e tipos de rede pudessem coexistir.
Apesar da disseminação de idéias de redes gerais, ainda existem muitos sistemas fechados que têm propósitos muito específicos. Neste ambiente, um protocolo simples e eficiente pode ser aplicado sem o perigo de incompatibilidades. Um exemplo é a rede de dispositivos em um automóvel moderno que se comunica através de uma rede. Do ponto de vista do autor, esses sistemas fechados, estreitamente fechados, são considerados sistemas de comunicação incorporados. Mesmo nesses sistemas embarcados, há um interesse crescente na conexão de sistemas embarcados a redes maiores para fins de monitoramento de status. Assim como os sistemas embarcados tomaram emprestados protocolos de comunicação e tecnologia a partir de sistemas de comunicação maiores, é provável que emprestem as muitas idéias de interconexão e padronização no futuro próximo.
A maioria dos sistemas de comunicação incorporados pode ser classificada como redes ponto-a-ponto (links de dados) ou redes de mídia compartilhada (rodovias de dados). É importante entender o trade-off entre estes dois tipos de sistemas. Nas redes ponto-a-ponto, cada nó do sistema está conectado a qualquer outro nó. Esses sistemas são simples e confiáveis. A confiabilidade é alta, uma vez que a transmissão correta entre dois nós depende apenas de um único transmissor e receptor. Uma vez que cada link é dedicado à comunicação entre dois nós, é fácil encontrar prazos em tempo real sem nenhum mecanismo de agendamento sofisticado. Nos sistemas de mídia compartilhados, todos os nós estão conectados usando uma topologia de barramento ou barramento. A principal motivação para meios compartilhados é a redução da fiação (e, portanto, o custo). Essas redes são facilmente extensíveis sem adicionar novas portas de dados a nós individuais. É necessário um novo cabeamento novo e limitado.
O preço da escalabilidade e do custo reduzido de uma rede de mídia compartilhada é a complexidade que deve ser adicionada ao protocolo de rede. Alguns meios devem ser adicionados para arbitrar para acessar a mídia compartilhada. A discussão restante neste artigo aplica-se principalmente a sistemas de comunicação embutidos de mídia compartilhada.
Comunicações baseadas em eventos versus estatais.
Na prática, os sistemas de comunicação podem não ser puramente eventos ou baseados em estados. Um protocolo de comunicação pode conter algumas propriedades de cada um. No entanto, é instrutivo examinar as diferenças fundamentais entre um sistema baseado em eventos e um sistema baseado em estado. Um dos compromissos fundamentais entre esses dois tipos de sistemas é o uso eficiente de recursos encontrados em sistemas baseados em eventos versus a base de previsão da rede encontrada em sistemas baseados em estado. Os principais recursos de preocupação na rede são a largura de banda (quantidade de dados que podem ser transmitidos por unidade de tempo) e o espaço de buffer necessário nos nós para processar mensagens recebidas ou enviadas.
Num sistema de comunicação baseado em eventos, as mensagens são geradas e transmitidas em resposta a "eventos" detectado em um nó local na rede. Exemplos de & quot; eventos & quot; incluem mudanças no valor das variáveis ​​de processo, novas condições de alarme que foram detectadas, condições que representam o apagamento de alarmes ou solicitações de outros nós para dados. Um exemplo de um sistema de comunicação baseado em eventos é a rede de escritório típica. As mensagens são geradas pelos usuários sempre que enviam dados para impressoras, acessam dados em unidades de rede compartilhadas, executam aplicativos que existem em outras máquinas ou enviam e-mails para outras pessoas na rede.
Um objetivo da comunicação baseada em eventos é o uso eficiente da largura de banda da rede. Ao transmitir apenas os dados necessários, é assegurada uma utilização eficiente da largura de banda da rede. No entanto, uma vez que os dados são transmitidos apenas quando há uma mudança no nó de origem, cada mensagem torna-se importante. Isso coloca requisitos adicionais no sistema de comunicação para garantir que cada mensagem seja entregue com sucesso. Um mecanismo para fazer isso é para os nós de destino reconhecer cada transmissão bem-sucedida e solicitar uma tentativa para cada mensagem corrompida. Se uma confirmação não for gerada dentro de um tempo limite especificado, o nó de origem também pode repetir a mensagem por conta própria. Observe que este mecanismo de confirmação e repetição consome alguma largura de banda de rede adicional.
Considere o exemplo de um sistema de monitoramento distribuído baseado em eventos. Este sistema monitora as condições da planta e gera alarmes quando determinadas condições são geradas. Durante o funcionamento normal, a rede deve ser ligeiramente carregada com poucas condições de alarme. Durante os transtornos do sistema, muitas mensagens serão necessárias devido a várias condições de alarme e mudança de estado. É difícil prever o número máximo de mensagens que podem ser trocadas durante esta situação. Muitos nós podem competir pelo canal de comunicação. Portanto, é difícil confirmar que um projeto do sistema conterá recursos adequados (largura de banda e buffers) para lidar com a carga. Para um sistema com funções de segurança, a rede está no seu pior (em termos de atraso e mensagens perdidas) quando é mais necessário. Esta condição às vezes é referida como o problema de inundação de alarme. Uma solução potencial para este problema é projetar uma rede excessivamente conservadora para atender a situação de pior caso. Esta abordagem pode não ser viável em um pequeno sistema integrado com restrições de custos.
Em um sistema de comunicação baseado em estado, as mensagens representam todo o estado de um nó. Por exemplo, todos os alarmes para um nó são transmitidos como ativados ou desativados em sua mensagem. Um nó envia sua mensagem de tamanho fixo em intervalos regulares pré-definidos. O acesso à mídia é agendado facilmente, uma vez que os requisitos de mensagem de cada nó nunca mudam. A carga da rede é fixa e pode ser facilmente calculada durante a concepção do sistema. Um exemplo de um sistema baseado em estado é um sistema de controle de processo distribuído. Cada nó possui um número fixo de entradas, valores calculados e condições de alarme que ele envia em sua mensagem para outros nós da rede.
O sistema baseado em estado é menos eficiente em termos de largura de banda da rede do que no sistema baseado em eventos. A largura de banda da rede é sacrificada pela previsibilidade do tamanho regular da mensagem e pelo acesso regular ao canal de comunicação. Observe que é possível uma redução nos dados gerais. Cada peça de dados ocupa uma localização fixa na mensagem. Portanto, os dados podem ser restritos ao valor. As informações sobre o que cada ponto de dados representa não são obrigadas a serem transmitidas com a mensagem.
Os sistemas baseados em estados podem ser projetados para tolerar a mensagem ocasional perdida. A re-transmissão pode não ser necessária, uma vez que todo o estado será transmitido novamente no próximo intervalo de tempo. Se as mensagens são transmitidas pelo dobro da frequência requerida, o sistema pode cumprir seus prazos, mesmo que cada segunda mensagem esteja corrompida. Para tolerar duas mensagens corrompidas em uma linha, cada nó poderia ser projetado para transmitir suas mensagens em três vezes a freqüência requerida.
Uma dificuldade em sistemas baseados em estados é a transmissão de dados transitórios. É importante que um nó de origem mantenha sinais momentâneos por uma duração suficiente para que todos os nós vejam os dados. Embora os dados persistam apenas por uma fração de um tempo de mensagem, um nó de origem pode precisar transmitir os dados em várias mensagens sucessivas. Esta situação momentânea é às vezes referida como o "alongamento do pulso" problema. Um exemplo de dados transitórios é um botão momentâneo que é uma entrada hard-wired para um único nó. Suponha que as indicações de pressionamentos de botão são necessárias em algum outro nó no sistema. Se a condição de que o botão tivesse sido pressionado fosse transmitida em apenas uma única mensagem e essa mensagem fosse perdida, outros nós seriam informados de que o botão tinha sido pressionado.
Encontrando o melhor protocolo em tempo real.
De acordo com [Kopetz97], nunca houve ou nunca será um protocolo em tempo real perfeito. Isso ocorre porque existem conflitos fundamentais nos requisitos que gostaríamos de colocar no sistema de comunicação. Esses requisitos são os melhores recursos de sistemas baseados em eventos e baseados em estado. Os conflitos refletem o trade-off entre a eficiência ou flexibilidade encontrada no sistema baseado em eventos e a previsibilidade encontrada no sistema estatal. Existem trade-offs para controle externo versus capacidade de compatividade, detecção de flexibilidade versus erro e proteção, dados esporádicos versus dados regulares, serviço espontâneo versus simplicidade de interface e acesso probabilístico versus determinismo de réplica. Para uma discussão detalhada de cada trade-off específico, consulte [Kopetz97].
Embora não "melhor" O protocolo existe, os designers de sistemas incorporados não são aliviados da tarefa de especificar um sistema de comunicação apropriado. Portanto, é importante focar os principais fatores diferenciadores encontrados nos protocolos. O modelo de referência OSI, mostrado na Figura 1, pode ser usado para examinar os protocolos de comunicação. Uma breve descrição da função de cada uma das camadas é fornecida abaixo. Para mais informações, consulte [Spragins94]
Figura 1: Modelo de Referência OSI Camada 7: Aplicação - Fornece interfaces padrão para diferentes tipos de transferência de dados, como transferência de correio ou arquivo.
Camada 6: Apresentação - Permite que os dados sejam apresentados ao aplicativo no formato nativo, permitindo a comunicação entre sistemas com diferentes representações de dados.
Camada 5: Sessão - Fornece um meio para que as aplicações estruturam um diálogo entre si.
Camada 4: Transporte - Fornece transferência transparente de dados e controle de fim a extremidade da transferência de mensagens.
Layer 3: Network - Fornece uma abstração da tecnologia de comunicação específica usada nas camadas mais baixas. Inclui as funções de roteamento e retransmissão de mensagens dentro da rede.
Camada 2: Ligação de dados - Fornece os procedimentos de acesso ao canal, iniciando e fechando links entre estações, agrupando caracteres em mensagens ou quadros, controle de erros e sincronização de quadros.
Sublayer LLC - O controle de Logical Link está preocupado principalmente com o estabelecimento e término de uma conexão virtual entre duas estações em uma rede. Sublayer MAC - Media Access Control se preocupa principalmente com arbitrar e conceder acesso ao canal comunitário.
Camada 1: Física - Fornece as características de transmissão elétrica ou óptica e a representação dos sinais. Esta camada também inclui os procedimentos utilizados para iniciar ou fechar a comunicação em um link físico.
Os sistemas incorporados tendem a se concentrar na camada 1 (física) e na camada 2 (link de dados) e usar camadas superiores mínimas ou inexistentes. Duas razões para esse foco podem ser 1) sistemas de comunicação embutidos são simples e não exigem serviços de nível superior 2) camadas superiores adicionam despesas gerais que não podem ser toleradas em alguns sistemas em tempo real. No entanto, esta situação pode mudar à medida que a complexidade aumenta nos sistemas incorporados e os usuários exigem mais recursos, como a interoperabilidade com outras redes. Para que várias redes possam comunicar uma interface comum é necessária. Uma camada superior comum no protocolo pode fornecer essa interface.
Dentro da camada de enlace de dados existe uma subcamada chamada controle de acesso de mídia (MAC) que determina muitas das características de um sistema de comunicação de mídia compartilhada. Várias técnicas de acesso à mídia foram propostas e utilizadas com sucesso em protocolos populares. Algumas técnicas comuns de acesso à mídia e protocolos que utilizam essas técnicas são abordadas abaixo.
CSMA / CD - Acesso múltiplo sentido portador com detecção de colisão. Cada nó monitora o canal ou o operador para determinar quando o canal está ocioso. Isso é conhecido como sentido de operadora. Se o nó tiver uma mensagem para enviar, começa a transmissão. O nó continua a monitorar o canal enquanto ele está transmitindo. Outro nó da rede também pode começar a transmitir no canal transparente. Neste caso, uma colisão seria detectada por ambos os nós. Os nós pararão de transmitir suas mensagens e enviarão um sinal de atolamento por um tempo suficiente para que todos os nós na rede vejam a colisão. Cada nó calcula e aguarda um intervalo aleatório antes de tentar novamente a transmissão. O protocolo Ethernet usado em LANs de escritório (redes de área local) popularizou este método de acesso. Mais tarde, foi padronizado como IEEE 802.3.
CSMA / CA - Acesso múltiplo sentido portador com colisão evasiva. O acesso inicial a um canal claro é realizado de forma semelhante ao CSMA / CD. No entanto, após uma colisão e um sinal de atolamento, as estações usam slots de contenção para resolver o acesso ao canal. Esses slots dão prioridade a um nó ou nó de acesso durante o seu espaço de contenção. Devido a esse espaço de contenção de prioridade, algumas colisões que ocorreram em tentativas em CSMA / CD são evitadas em CSMA / CA. As atribuições de slots são giradas entre colisões sucessivas para garantir a equidade. Um exemplo desse protocolo é LONWorks.
Polling - Na polling, um único nó mestre controla o acesso ao canal. Todos os outros nós são consultados sequencialmente para determinar se eles têm mensagens para enviar. Se eles tiverem mensagens, eles têm acesso para enviar suas mensagens. Observe que este método depende muito da operação correta do mestre. O BitBus da Intel e muitos protocolos de comunicação fieldbus usam esse método.
Bit Dominance - Em protocolos de dominância de bits, todos os nós são sincronizados. Cada nó inicia a transmissão em um canal transparente enviando seu nó ou ID da mensagem. Esta ID indica a prioridade de sua transmissão. O nó com a ID mais alta ganha o lance porque os 1's em sua ID dominam qualquer 0 enviada por outros nós. Note-se que isso requer uma mídia elétrica onde enviou 1 domina mais de 0's. A Rede de Área do Controlador (CAN) com base neste método de acesso é muito usada em automóveis.
Passo de token - Na passagem de token, o acesso ao canal é determinado pelo suporte de um token. Quando este nó é terminado de transmitir, ele passa o token em uma mensagem especial para o próximo nó na rede. Se um nó não tiver mensagens para enviar, simplesmente passa o token. Os processos de licitação especiais são muitas vezes necessários para estabelecer o suporte inicial do token e quanto tempo cada nó pode armazenar o token. O anel de token da IBM, o barramento de token e o FDDI (interface de dados distribuídos por fibra) usam alguma forma de passagem de token.
TDMA - Acesso múltiplo por divisão de tempo. Neste método de acesso, a largura de banda da rede é cortada em slots. Cada nó é alocado com um ou mais slots onde tem acesso exclusivo ao canal. Os slots repetem continuamente, dando a cada nó acesso periódico ao canal. ARINC 629 (Aeronautical Radio Incorporation) é um protocolo estabelecido para redes de avião embutidas que utilizam esse método. Outro protocolo TDMA projetado especificamente para aplicações em tempo real tolerantes a falhas é TTP (protocolo ativado por tempo). Este protocolo é um desenvolvimento relativamente recente (1993) e suas aplicações em sistemas incorporados reais são desconhecidas para o autor.
Estudos de protocolos individuais foram realizados e publicados em revistas. Infelizmente, apenas foram realizadas comparações limitadas dos protocolos utilizados em sistemas incorporados. Consulte [Koopman94] para uma comparação qualitativa de protocolos utilizados em sistemas embarcados e uma cobertura mais detalhada sobre técnicas individuais de acesso a mídia.
Embora os próprios protocolos não sejam estritamente baseados em eventos ou estados, eles geralmente se prestam mais facilmente a um ou a outro tipo de sistema. Por exemplo, o CSMA / CD usado em Ethernet é um método de acesso probabilístico. Os sistemas baseados em eventos se encaixam bem com este protocolo devido à natureza esporádica das mensagens. Os protocolos de multiplexação por divisão de tempo dividem a largura de banda da rede em fatias de tempo para nós individuais. Os sistemas baseados em estado podem usar eficientemente uma ou mais fatias de tempo para enviar seus dados regulares.
Detecção / Diagnóstico de Erros.
A detecção e o diagnóstico de erros são importantes em qualquer sistema incorporado e especialmente em sistemas críticos de segurança. Os sistemas de comunicação são bastante avançados em suas capacidades para detectar, tolerar e às vezes corrigir erros. Na Tabela 1, alguns erros típicos para sistemas de comunicação estão listados. Junto com cada tipo de erro, são discutidas as defesas típicas disponíveis no sistema de comunicação. O conhecimento de tipos de erros e defesas comuns é inestimável para o designer do sistema.
Ruído do canal - O ruído é tipicamente induzido nos canais de comunicação do ambiente ou através de conversação de fios adjacentes. Uma técnica para reduzir o ruído é o uso de fibra óptica para o canal de comunicação. As fibras são impermeáveis ​​à interferência eletromagnética. Os checksums de redundância cíclica (CRC) são frequentemente anexados a mensagens. Estas somas de verificação permitem a detecção de todos os erros de múltiplos e múltiplos erros induzidos nas mensagens. Técnicas de codificação de erros mais sofisticadas também podem ser usadas para corrigir erros de bits.
Mensagens fechadas - As mensagens antigas que não representam dados precisos em tempo real podem estar presentes no sistema. Alguns protocolos incluem um horário que é inserido pela fonte para marcar a idade da mensagem. Observe que isso implica uma base de tempo global.
Mensagens repetidas - Em certas falhas de um nó host ou de sua interface de rede, a mesma mensagem pode ser continuamente repetida. Alguns protocolos incluem um número de série para cada mensagem. Os nós de destino podem facilmente detectar mensagens repetidas ou fora de sequência.
Propagação de falhas - Em um sistema de mídia compartilhado, é importante evitar que falhas em um nó se propagem para outros nós. A proteção contra surtos geralmente é incluída para evitar a propagação de falhas elétricas. Os cabos de fibra óptica servem de isolamento galvânico entre nós. As redes redundantes também podem impedir a propagação.
Execução de estação - As estações podem falhar de forma a monopolizar a mídia compartilhada. Alguns protocolos, como Ethernet, contêm um circuito de supervisão anti-jabber. Esses circuitos limitam o tempo que qualquer estação permite o acesso à mídia. A estação será bloqueada até que um período de silêncio especificado seja observado.
Erros de memória - Interno para um nó, uma mensagem pode ser copiada várias vezes. As cópias normalmente são feitas em transações DMA ou outras trocas entre um nó host e seu chipset de interface de rede. É possível adicionar checksums de informações a mensagens que podem ser usadas para detectar erros de memória no processo de cópia.
Falhas no hardware da interface - o hardware da interface de comunicação pode falhar. Os diagnósticos estão incluídos em muitos sistemas de comunicação que permitem o teste de loopback das interfaces.
Erros intermitentes - Os erros podem começar a ocorrer a uma taxa mais alta que está abaixo do limite para erros do sistema. No entanto, o aumento desses erros pode sinalizar uma parte ruim ou conexão no sistema. Muitos chipsets de comunicação incluem contadores estatísticos que mostram taxas e tipos de erro. Se relatado ao nível do sistema, esses erros podem sinalizar a ação de manutenção antes que as falhas do sistema ocorram.
Quebra de cabo - A perda de comunicação através de pausas de cabo normalmente é detectável através da perda de sinal. No entanto, alguns sistemas de comunicação incluem capacidades tolerantes a falhas que toleram quebras de cabo. Um exemplo é o FDDI, que é configurado como anéis de rotação. As estações individuais podem reconfigurar os anéis para ignorar as quebras do cabo.
Os analisadores de protocolos podem ser anexados à maioria das redes para examinar dados no bit, personagem e nível do quadro. Os cabeçalhos para protocolos comuns podem ser descodificados automaticamente. Esses analisadores são particularmente úteis para examinar erros e violações de protocolos.
Os reflectômetros de domínio do tempo podem analisar o cabeamento e conexões em redes. Existem versões desse equipamento para meios elétricos e de fibra óptica. Eles são úteis para encontrar rupturas de cabo, conexões ruins e determinar os comprimentos dos cabos. Esses instrumentos funcionam enviando uma onda por um cabo e examinando as reflexões. Cada reflexão representa uma conexão ou impefecção no cabo. Em fibra óptica, a qualidade da conexão é extremamente importante. Esses instrumentos podem determinar a perda no nível de sinal introduzido por cada conexão.
Foram aplicadas técnicas de métodos formais para a verificação de protocolos de comunicação (Petri Nets, Lotos, SDL, Z & # 133;). As redes Petri, em particular, foram criadas para analisar redes de comunicação. A verificação de um protocolo normalmente é necessária durante o processo de padronização. Um certo nível de correção pode ser assegurado pelo designer do sistema incorporado se ele escolher um protocolo padronizado.
Um esforço mais provável para os designers de sistemas embutidos é a seleção de um sistema de comunicação. Para fazer isso, é necessário um bom controle sobre os requisitos e questões-chave envolvidas na decisão. Uma lista dos problemas e recomendações específicas são apresentadas em [Preckshot93] NUREG / CR-6082, Comunicação de dados. Este documento foi desenvolvido como um guia para as autoridades reguladoras a serem usadas ao avaliar os sistemas propostos. Mesmo que seja destinado à indústria nuclear, ele é aplicável a outros sistemas embarcados, pois solicita questões focadas sobre o sistema de comunicação.
As métricas comuns publicadas na literatura do fabricante são taxas de dados e taxas de erro. Os estudos de protocolo fornecem medidas mais detalhadas do desempenho que pode ser esperado. Esses estudos envolvem técnicas complexas de modelagem e simulação. Não é surpreendente que as comparações quantitativas em larga escala entre muitos protocolos não tenham sido tentadas. Exemplos das métricas encontradas nos estudos de protocolos são a taxa de transferência versus carga, atraso versus taxa de transferência e a utilização do pior caso.
Em geral, a teoria da comunicação e as técnicas de análise são bastante maduras. No entanto, o processo de seleção do sistema de comunicação é ad hoc, na melhor das hipóteses.
A comunicação pode ser considerada como uma forma de E / S. No entanto, uma relação mais aplicável pode ser a tendência atual de usar ônibus de campo para se comunicar com E / S.
A arquitetura de comunicação é muitas vezes o método usado para alcançar um sistema confiável confiável, normalmente através de redundância.
Os sistemas de comunicação incorporados são na maioria das vezes sistemas em tempo real. O tópico em tempo real abrange a programação, o que é importante nas redes de mídia compartilhada.
A comunicação permite a computação tolerante a falhas através do uso da detecção de erros.
As técnicas de codificação de erros são freqüentemente usadas na comunicação para detecção de erros, correção de erros, confiabilidade, compressão e relação sinal / ruído ideal.
Os métodos formais são freqüentemente usados ​​para a verificação do protocolo de comunicação.
Existe um compromisso fundamental entre eficiência e previsibilidade na seleção de um sistema baseado em eventos ou de um sistema baseado em estado. Independentemente da decisão, há deficiências que devem ser abordadas. A falta de uma comparação quantitativa detalhada de protocolos coloca o fardo da avaliação do sistema de comunicação diretamente no designer do sistema incorporado. Muitas das propriedades do sistema de comunicação são determinadas pelo protocolo de acesso à mídia. Portanto, os designers de sistemas incorporados devem se concentrar no método de acesso à mídia ao determinar o protocolo a ser usado. Outros fatores importantes a considerar incluem a tecnologia de comunicação e seu custo ou longevidade. Muitas vezes ignorado no design são as condições de erro. Os sistemas de comunicação possuem uma variedade de mecanismos que podem ser usados ​​para detectar erros. Utilizando esses métodos de detecção, o designer pode criar um sistema de comunicação confiável.
[Koopman94] Koopman, PJ e Upender, BP, "Protocolos de comunicação para sistemas embutidos", Programação de sistemas incorporados, 7 (11), novembro de 1994, pp. 46-48, cs. cmu. edu/People/koopman/protsrvy /protsrvy. html, Acessado: 8 de maio de 1999.
Notas: Boa comparação qualitativa de protocolos, especialmente a variedade de métodos de acesso à mídia disponíveis. Prático. Escrito em um nível introdutório. Examina diferentes métodos de acesso à mídia com algum detalhe.
[Kopetz97] Kopetz, H., Sistemas em Tempo Real, Princípios de Design para Aplicações Incorporadas Distribuídas, Klower Academic Publishers, 1997, Chpt.7-8.
Notas: ampla variedade de informações em sistemas em tempo real. Uma discussão chave examina cinco compromissos fundamentais nos requisitos ideais dos sistemas de comunicação. A seção de comunicação mostra o viés para o Protocolo de Triggerd de Tempo (TTP) sobre o qual ele escreveu outros artigos.
Notas: Escrito a partir do ponto de vista do avaliador de um sistema de segurança para sistemas críticos. No entanto, este documento faz todas as perguntas que um designer do sistema integrado deve se perguntar. O apêndice é mais tutorial por natureza.
[Spragins94] Spragins, J. D., Hammond, J. L., e Pawlikowski, K., Telecommunications Protocols and Design, Addison Wesley Publishing, 1994.
Notas: Boa fonte de matemática de comunicação, teoria da fila e métricas. Infelizmente, os exemplos cobertos são protocolos de comunicação padrão em vez de protocolos de sistema incorporados. Esta referência também fornece um bom histórico sobre o Modelo de Referência OSI e as redes de comunicação em geral.
Leitura adicional.
[Norden98] Norden, S., Manimaran, G., Siva Ram Murthy, C., "Novos protocolos para comunicação em tempo real em ambiente LAN comutado", Procedimentos - 23ª Conferência Internacional sobre Redes de Computadores Locais, IEEE Computer Society , 1998, pp. 364-373.
Notas: A discussão é mais adaptada ao uso de redes de telecomunicações existentes. Não é tão aplicável aos sistemas embarcados. Esta pode ser uma questão futura. Abrange o problema da QOS e a mistura de tipos de tráfego.
[Paige90] Paige, Lt. J. L., "SAFENET - Uma abordagem da Marinha para a Rede de Computadores", Procedimentos - 15ª Conferência Internacional sobre Redes de Computadores Locais, IEEE Computer Society, 1990, pp. 268-273.
Notas: Arquitetura de alto nível de dois sistemas de comunicação críticos de segurança. Um é baseado em Ethernet, o outro no FDDI.
Notas: Tenta prever se a Ethernet se espalhará para o piso da fábrica. Pode ser muito opinativo. Não é muito forte em argumentos de apoio. Pode ter uma agenda escondida, já que está no site do empregador.
[Raman90] Ramanathan, P., Shin, K. G., Butler R. W., "Sincronização de relógio com tolerância a falhas em sistemas distribuídos", IEEE Computer, 23 (10), 1990, pp. 33-42.
Notas: Este é um grande problema para alguns protocolos como o TDMA (e para algumas aplicações que exigem sequência de eventos). Obtém o problema do Bizantino Geral para a sincronização na presença de relógios defeituosos. Há muitos artigos sobre esse problema. [Kopetz97] também tem um.
[Scholl88] Scholl, F. W. e Coden, M. H., "Sistemas de estrelas ópticas passivas para redes de área local de fibra óptica", transações IEEE em áreas selecionadas em comunicações, 6 (6), 1988, pp.913-923.
Notas: boa ideia porque a conexão de rede é passiva e, portanto, mais confiável. Infelizmente, este método pode não ser suportado pela tecnologia atual. Perdas elevadas em estrelas só funcionam com transmissores fortes. Ok, nos primeiros dias, quando os transmissores de fibra óptica eram de alta potência. Agora, a maioria dos transmissores são LEDs com menor potência de saída.
[Upender97] Upender, B. P. e Dean, A., "Embedded Communication Network Pitfalls", Programação de sistemas incorporados, 10 (9), 1997, embedded / 97 / fe29709.htm, Acessado: 8 de maio de 1999.
Notas: Análise dos problemas com protocolos para determinadas aplicações, mas cobre apenas 3 (LonTalk, CAN e IEEE-1394).
[Zhao95] Zhao, W. e Malcolm N., "Comunicação em tempo real em redes de acesso múltiplo", Real Time Systems, 8, 1995, pp.35-77.
Notas: Análise aprofundada de tipos de MAC. Inclina-se em direção a matemática.

Problemas de design do sistema incorporado.
(O resto da história)
Preprint of paper publicado em:
Procedimentos da Conferência Internacional sobre Design de Computadores (ICCD 96)
em conjunto com uma sessão tutorial incorporada do mesmo título.
Muitos sistemas incorporados apresentam restrições de design substancialmente diferentes das aplicações de computação de desktop. Nenhuma caracterização única se aplica ao espectro diversificado de sistemas embarcados. No entanto, uma combinação de pressão de custo, longo ciclo de vida, requisitos em tempo real, requisitos de confiabilidade e disfunção de cultura de design podem dificultar a implementação de metodologias e ferramentas de design de computadores tradicionais para aplicativos embutidos. Os sistemas embutidos em muitos casos devem ser otimizados para fatores de ciclo de vida e de negócios, em vez de para o rendimento de computação máximo. Atualmente, há pouco suporte para ferramentas para expandir o design do computador incorporado para o escopo do design integrado do sistema integrado. No entanto, conhecer os pontos fortes e fracos das abordagens atuais pode definir as expectativas adequadamente, identificar as áreas de risco para os usuários de ferramentas e sugerir maneiras pelas quais os construtores de ferramentas podem atender às necessidades industriais.
1. Introdução.
Aproximadamente 3 bilhões de CPUs embutidas são vendidas a cada ano, com CPUs menores (4-, 8 e 16 bits) dominando por quantidade e quantidade agregada em dólares [1]. No entanto, a maior parte do desenvolvimento de pesquisas e ferramentas parece estar focada nas necessidades da computação embutida desktop e militar / aeroespacial high-end. Este artigo procura expandir a área de discussão para abranger uma ampla gama de sistemas embarcados.
A extrema diversidade das aplicações embutidas torna as generalizações difíceis. No entanto, há um interesse emergente em toda a gama de sistemas incorporados (por exemplo, [2], [3], [4], [5], [6]) e o campo relacionado de códigos de hardware / software (por exemplo, [7 ]).
This paper and the accompanying tutorial seek to identify significant areas in which embedded computer design differs from more traditional desktop computer design. They also present "design challenges" encountered in the course of designing several real systems. These challenges are both opportunities to improve methodology and tool support as well as impediments to deploying such support to embedded system design teams. In some cases research and development has already begun in these areas -- and in other cases it has not.
The observations in this paper come from the author's experience with commercial as well as military applications, development methodologies, and life-cycle support. All characterizations are implicitly qualified to indicate a typical, representative, or perhaps simply an anecdotal case rather than a definitive statement about all embedded systems. While it is understood that each embedded system has its own set of unique requirements, it is hoped that the generalizations and examples presented here will provide a broad-brush basis for discussion and evolution of CAD tools and design methodologies.
2. Example Embedded Systems.
Figure 1 shows one possible organization for an embedded system.
Figure 1. An embedded system encompasses the CPU as well as many other resources.
In addition to the CPU and memory hierarchy, there are a variety of interfaces that enable the system to measure, manipulate, and otherwise interact with the external environment. Some differences with desktop computing may be:
The human interface may be as simple as a flashing light or as complicated as real-time robotic vision. The diagnostic port may be used for diagnosing the system that is being controlled -- not just for diagnosing the computer. Special-purpose field programmable (FPGA), application specific (ASIC), or even non-digital hardware may be used to increase performance or safety. Software often has a fixed function, and is specific to the application.
In addition to the emphasis on interaction with the external world, embedded systems also provide functionality specific to their applications. Instead of executing spreadsheets, word processing and engineering analysis, embedded systems typically execute control laws, finite state machines, and signal processing algorithms. They must often detect and react to faults in both the computing and surrounding electromechanical systems, and must manipulate application-specific user interface devices.
Table 1. Four example embedded systems with approximate attributes.
In order to make the discussion more concrete, we shall discuss four example systems (Table 1). Each example portrays a real system in current production, but has been slightly genericized to represent a broader cross-section of applications as well as protect proprietary interests. The four examples are a Signal Processing system, a Mission Critical control system, a Distributed control system, and a Small consumer electronic system. The Signal Processing and Mission Critical systems are representative of traditional military/aerospace embedded systems, but in fact are becoming more applicable to general commercial applications over time.
Using these four examples to illustrate points, the following sections describe the different areas of concern for embedded system design: computer design, system-level design, life-cycle support, business model support, and design culture adaptation.
Desktop computing design methodology and tool support is to a large degree concerned with initial design of the digital system itself. To be sure, experienced designers are cognizant of other aspects, but with the recent emphasis on quantitative design ( e. g. , [8]) life-cycle issues that aren't readily quantified could be left out of the optimization process. However, such an approach is insufficient to create embedded systems that can effectively compete in the marketplace. This is because in many cases the issue is not whether design of an immensely complex system is feasible, but rather whether a relatively modest system can be highly optimized for life-cycle cost and effectiveness.
While traditional digital design CAD tools can make a computer designer more efficient, they may not deal with the central issue -- embedded design is about the system, not about the computer. In desktop computing, design often focuses on building the fastest CPU, then supporting it as required for maximum computing speed. In embedded systems the combination of the external interfaces (sensors, actuators) and the control or sequencing algorithms is or primary importance. The CPU simply exists as a way to implement those functions. The following experiment should serve to illustrate this point: ask a roomful of people what kind of CPU is in the personal computer or workstation they use. Then ask the same people which CPU is used for the engine controller in their car (and whether the CPU type influenced the purchasing decision).
In high-end embedded systems, the tools used for desktop computer design are invaluable. However, many embedded systems both large and small must meet additional requirements that are beyond the scope of what is typically handled by design automation. These additional needs fall into the categories of special computer design requirements, system-level requirements, life-cycle support issues, business model compatibility, and design culture issues.
3. Computer Design Requirements.
Embedded computers typically have tight constraints on both functionality and implementation. In particular, they must guarantee real time operation reactive to external events, conform to size and weight limits, budget power and cooling consumption, satisfy safety and reliability requirements, and meet tight cost targets.
3.1. Real time/reactive operation.
Real time system operation means that the correctness of a computation depends, in part, on the time at which it is delivered. In many cases the system design must take into account worst case performance. Predicting the worst case may be difficult on complicated architectures, leading to overly pessimistic estimates erring on the side of caution. The Signal Processing and Mission Critical example systems have a significant requirement for real time operation in order to meet external I/O and control stability requirements.
Reactive computation means that the software executes in response to external events. These events may be periodic, in which case scheduling of events to guarantee performance may be possible. On the other hand, many events may be aperiodic, in which case the maximum event arrival rate must be estimated in order to accommodate worst case situations. Most embedded systems have a significant reactive component.
Worst case design analyses without undue pessimism in the face of hardware with statistical performance characteristics ( e. g., cache memory [9]).
3.2. Small size, low weight.
Many embedded computers are physically located within some larger artifact. Therefore, their form factor may be dictated by aesthetics, form factors existing in pre-electronic versions, or having to fit into interstices among mechanical components. In transportation and portable systems, weight may be critical for fuel economy or human endurance. Among the examples, the Mission Critical system has much more stringent size and weight requirements than the others because of its use in a flight vehicle, although all examples have restrictions of this type.
Non-rectangular, non-planar geometries. Packaging and integration of digital, analog, and power circuits to reduce size.
3.3. Safe and reliable.
Some systems have obvious risks associated with failure. In mission-critical applications such as aircraft flight control, severe personal injury or equipment damage could result from a failure of the embedded computer. Traditionally, such systems have employed multiply-redundant computers or distributed consensus protocols in order to ensure continued operation after an equipment failure ( e. g. , [10], [11])
However, many embedded systems that could cause personal or property damage cannot tolerate the added cost of redundancy in hardware or processing capacity needed for traditional fault tolerance techniques. This vulnerability is often resolved at the system level as discussed later.
Low-cost reliability with minimal redundancy.
3.4. Harsh environment.
Many embedded systems do not operate in a controlled environment. Excessive heat is often a problem, especially in applications involving combustion ( e. g., many transportation applications). Additional problems can be caused for embedded computing by a need for protection from vibration, shock, lightning, power supply fluctuations, water, corrosion, fire, and general physical abuse. For example, in the Mission Critical example application the computer must function for a guaranteed, but brief, period of time even under non-survivable fire conditions.
Accurate thermal modelling. De-rating components differently for each design, depending on operating environment.
3.5. Cost sensitivity.
Even though embedded computers have stringent requirements, cost is almost always an issue (even increasingly for military systems). Although designers of systems large and small may talk about the importance of cost with equal urgency, their sensitivity to cost changes can vary dramatically. A reason for this may be that the effect of computer costs on profitability is more a function of the proportion of cost changes compared to the total system cost, rather than compared to the digital electronics cost alone. For example, in the Signal Processing system cost sensitivity can be estimated at approximately $1000 ( i. e. , a designer can make decisions at the $1000 level without undue management scrutiny). However, with in the Small system decisions increasing costs by even a few cents attract management attention due to the huge multiplier of production quantity combined with the higher percentage of total system cost it represents.
Variable "design margin" to permit tradeoff between product robustness and aggressive cost optimization.
4. System-level requirements.
In order to be competitive in the marketplace, embedded systems require that the designers take into account the entire system when making design decisions.
4.1. End-product utility.
The utility of the end product is the goal when designing an embedded system, not the capability of the embedded computer itself. Embedded products are typically sold on the basis of capabilities, features, and system cost rather than which CPU is used in them or cost/performance of that CPU.
One way of looking at an embedded system is that the mechanisms and their associated I/O are largely defined by the application. Then, software is used to coordinate the mechanisms and define their functionality, often at the level of control system equations or finite state machines. Finally, computer hardware is made available as infrastructure to execute the software and interface it to the external world. While this may not be an exciting way for a hardware engineer to look at things, it does emphasize that the total functionality delivered by the system is what is paramount.
Software - and I/O-driven hardware synthesis (as opposed to hardware-driven software compilation/synthesis).
4.2. System safety & reliability.
An earlier section discussed the safety and reliability of the computing hardware itself. But, it is the safety and reliability of the total embedded system that really matters. The Distributed system example is mission critical, but does not employ computer redundancy. Instead, mechanical safety backups are activated when the computer system loses control in order to safely shut down system operation.
A bigger and more difficult issue at the system level is software safety and reliability. While software doesn't normally "break" in the sense of hardware, it may be so complex that a set of unexpected circumstances can cause software failures leading to unsafe situations. This is a difficult problem that will take many years to address, and may not be properly appreciated by non-computer engineers and managers involved in system design decisions ([12] discusses the role of computers in system safety).
Reliable software. Cheap, available systems using unreliable components. Electronic vs. non-electronic design tradeoffs.
4.3. Controlling physical systems.
The usual reason for embedding a computer is to interact with the environment, often by monitoring and controlling external machinery. In order to do this, analog inputs and outputs must be transformed to and from digital signal levels. Additionally, significant current loads may need to be switched in order to operate motors, light fixtures, and other actuators. All these requirements can lead to a large computer circuit board dominated by non-digital components.
In some systems "smart" sensors and actuators (that contain their own analog interfaces, power switches, and small CPUS) may be used to off-load interface hardware from the central embedded computer. This brings the additional advantage of reducing the amount of system wiring and number of connector contacts by employing an embedded network rather than a bundle of analog wires. However, this change brings with it an additional computer design problem of partitioning the computations among distributed computers in the face of an inexpensive network with modest bandwidth capabilities.
Distributed system tradeoffs among analog, power, mechanical, network, and digital hardware plus software.
4.4. Power management.
A less pervasive system-level issue, but one that is still common, is a need for power management to either minimize heat production or conserve battery power. While the push to laptop computing has produced "low-power" variants of popular CPUs, significantly lower power is needed in order to run from inexpensive batteries for 30 days in some applications, and up to 5 years in others.
Ultra-low power design for long-term battery operation.
5. Life-cycle support.
Figure 2 shows one view of a product life-cycle (a simplified version of the view taken by [13]).
Figure 2. An embedded system lifecycle.
First a need or opportunity to deploy new technology is identified. Then a product concept is developed. This is followed by concurrent product and manufacturing process design, production, and deployment. But in many embedded systems, the designer must see past deployment and take into account support, maintenance, upgrades, and system retirement issues in order to actually create a profitable design. Some of the issues affecting this life-cycle profitability are discussed below.
5.1. Component acquisition.
Because an embedded system may be more application-driven than a typical technology-driven desktop computer design, there may be more leeway in component selection. Thus, component acquisition costs can be taken into account when optimizing system life-cycle cost. For example, the cost of a component generally decreases with quantity, so design decisions for multiple designs should be coordinated to share common components to the benefit of all.
Life-cycle, cross-design component cost models and optimization rather than simple per-unit cost.
5.2. System certification.
Embedded computers can affect the safety as well as the performance the system. Therefore, rigorous qualification procedures are necessary in some systems after any design change in order to assess and reduce the risk of malfunction or unanticipated system failure. This additional cost can negate any savings that might have otherwise been realized by a design improvement in the embedded computer or its software. This point in particular hinders use of new technology by resynthesizing hardware components -- the redesigned components cannot be used without incurring the cost of system recertification.
One strategy to minimize the cost of system recertification is to delay all design changes until major system upgrades occur. As distributed embedded systems come into more widespread use, another likely strategy is to partition the system in such a way as to minimize the number of subsystems that need to be recertified when changes occur. This is a partitioning problem affected by potential design changes, technology insertion strategies, and regulatory requirements.
Partitioning/synthesis to minimize recertification costs.
5.3. Logistics and repair.
Whenever an embedded computer design is created or changed, it affects the downstream maintenance of the product. A failure of the computer can cause the entire system to be unusable until the computer is repaired. In many cases embedded systems must be repairable in a few minutes to a few hours, which implies that spare components and maintenance personnel must be located close to the system. A fast repair time may also imply that extensive diagnosis and data collection capabilities must be built into the system, which may be at odds with keeping production costs low.
Because of the long system lifetimes of many embedded systems, proliferation of design variations can cause significant logistics expenses. For example, if a component design is changed it can force changes in spare component inventory, maintenance test equipment, maintenance procedures, and maintenance training. Furthermore, each design change should be tested for compatibility with various system configurations, and accommodated by the configuration management database.
Designs optimized to minimize spares inventory. High-coverage diagnosis and self-test at system level, not just digital component level.
5.4. Upgrades.
Because of the long life of many embedded systems, upgrades to electronic components and software may be used to update functionality and extend the life of the embedded system with respect to competing with replacement equipment. While it may often be the case that an electronics upgrade involves completely replacing circuit boards, it is important to realize that the rest of the system will remain unchanged. Therefore, any special behaviors, interfaces, and undocumented features must be taken into account when performing the upgrade. Also, upgrades may be subject to recertification requirements.
Of special concern is software in an upgraded system. Legacy software may not be executable on upgraded replacement hardware, and may not be readily cross-compiled to the new target CPU. Even worse, timing behavior is likely to be different on newer hardware, but may be both undocumented and critical to system operation.
Ensuring complete interface, timing, and functionality compatibility when upgrading designs.
5.5. Long-term component availability.
When embedded systems are more than a few years old, some electronic components may no longer be available for production of new equipment or replacements. This problem can be especially troublesome with obsolete processors and small-sized dynamic memory chips.
When a product does reach a point at which spare components are no longer economically available, the entire embedded computer must sometimes be redesigned or upgraded. This redesign might need to take place even if the system is no longer in production, depending on the availability of a replacement system. This problem is a significant concern on the Distributed example system.
Cost-effectively update old designs to incorporate new components.
6. Business model.
The business models under which embedded systems are developed can vary as widely as the applications themselves. Costs, cycle time, and the role of product families are all crucial business issues that affect design decisions.
6.1. Design vs. production costs.
Design costs, also called Non-Recurring Engineering costs (NRE), are of major importance when few of a particular embedded system are being built. Conversely, production costs are important in high-volume production. Embedded systems vary from single units to millions of units, and so span the range of tradeoffs between design versus production costs.
At the low-volume end of the spectrum, CAD tools can help designers complete their work with a minimum of effort. However, at the high-volume end of the spectrum the designs may be simple enough and engineering cost such a small fraction of total system cost that extensive hand-optimization is performed in order to reduce production costs.
CAD tools may be able to outperform an average engineer at all times, and a superior engineer on very large designs (because of the limits of human capacity to deal with complexity and repetition). However, in small designs some embedded computer designers believe that a superior human engineer can outperform CAD tools. In the Small system example a programmer squeezed software into a few hundred bytes of memory by hand when the compiler produced overly large output that needed more memory than was available. It can readily be debated whether CAD tools or humans are "better" designers, but CAD tools face skepticism in areas that require extraordinary optimization for size, performance, or cost.
Intelligently trade off design time versus production cost.
6.2. Cycle time.
The cycle time between identification of a product opportunity and product deployment (also called Time to Market) can be quite long for embedded systems. In many cases the electronics are not the driving force; instead, product schedules are driven by concerns such as tooling for mechanical components and manufacturing process design. Superficially, this would seem to imply that design time for the electronics is not an overriding concern, but this is only partially true.
Because the computer system may have the most malleable design, it may absorb the brunt of changes. For example, redesign of hardware was required on the Mission Critical example system when it was found that additional sensors and actuators were needed to meet system performance goals. On the Small example system, delays in making masked ROM changes in order to revise software dominate concerns about modifications (and programmable memory is too expensive). So, although the initial design is often not in the critical path to product deployment, redesign of the computer system may need to be done quickly to resolve problems.
Rapid redesign to accommodate changing form factors, control algorithms, and functionality requirements.
6.3. Product families.
In many cases embedded system designs are not unique, and there are a variety of systems of various prices and capabilities forming a product family. To the extent that system designers can reuse components, they lower the total cost of all systems in the product family.
However, there is a dynamic tension between overly general solutions that satisfy a large number of niche requirements, and specifically optimized designs for each point in a product family space. Also, there may be cases in which contradictory requirements between similar systems prevent the use of a single subsystem design. In the Mission Critical and Small examples different customers require different interfaces between the embedded system and their equipment. In the Distributed example regulatory agencies impose different safety-critical behavior requirements depending on the geographic area in which the system is deployed.
Customize designs while minimizing component variant proliferation.
7. Design culture.
Design is a social activity as well as a technical activity. The design of desktop computers, and CPUs in particular, has matured in terms of becoming more quantitative in recent years. With this new maturity has come an emphasis on simulation and CAD tools to provide engineering tradeoffs based on accurate performance and cost predictions.
Computer designers venturing into the embedded arena must realize that their culture (and the underlying tool infrastructure) are unlike what is commonly practiced in some other engineering disciplines. But, because embedded system design requires a confluence of engineering skills, successful computer designers and design methodologies must find a harmonious compromise with the techniques and methodologies of other disciplines as well as company management. Also, in many cases the engineers building embedded computer systems are not actually trained in computer engineering (or, perhaps not even electrical engineering), and so are not attuned to the culture and methodologies of desktop computer design.
7.1. Computer culture vs. other cultures.
A specific problem is that computer design tools have progressed to the point that many believe it is more cost-effective to do extensive simulation than build successive prototypes. However, in the mechanical arena much existing practice strongly favors prototyping with less exhaustive up-front analysis. Thus, it may be difficult to convince project managers (who may be application area specialists rather than computer specialists) to spend limited capital budgets on CAD tools and defer the gratification of early prototype development in favor of simulation.
Make simulation-based computer design accessible to non-specialists.
7.2. Accounting for cost of engineering design.
One area of common concern is the effectiveness of using engineers in any design discipline. But, some computer design CAD tools are very expensive, and in general organizations have difficulty trading off capital and tool costs against engineering time. This means that computer designers may be deprived of CAD tools that would reduce the total cost of designing a system.
Also, in high-volume applications engineering costs can be relatively small when compared to production costs. Often, the number of engineers is fixed, and book-kept as a constant expense that is decoupled from the profitability of any particular system design, as is the case in all four example systems. This can be referred to as the "Engineers Are Free" síndrome. But, while the cost of engineering time may have a small impact on product costs, the unavailability of enough engineers to do work on all the products being designed can have a significant opportunity cost (which is, in general, unmeasured).
Improved productivity via using tools and methodologies may be better received by managers if it is perceived to increase the number of products that can be designed, rather than merely the efficiency of engineers on any given product design effort. This is a subtle but, in practice, important distinction.
7.3. Inertia.
In general, the cost of change in an organization is high both in terms of money and organizational disruption. The computer industry can be thought of as being forced to change by inexorable exponential growth in hardware capabilities. However, the impact of this growth seems to have been delayed in embedded system development. In part this is because of the long time that elapses between new technology introduction and wide-scale use in inexpensive systems. Thus, it may simply be that complex designs will force updated CAD tools and design methodologies to be adopted for embedded systems in the near future.
On the other hand, the latest computer design technologies may not have been adopted by many embedded system makers because they aren't necessary. Tool development that concentrates on the ability to handle millions of transistors may simply not be relevant to designers of systems using 4- and 8-bit microprocessors that constitute the bulk of the embedded CPU market. And, even if they are useful, the need for them may not be compelling enough to justify the pain and up-front expense of change so long as older techniques work.
That is not to say that new tools aren't needed, but rather that the force of cultural inertia will only permit adoption of low-cost tools with significant advantages to the problem at hand .
Find/create design tools and methodologies that provide unique, compelling advantages for embedded design.
8. Conclusions.
Many embedded systems have requirements that differ significantly both in details and in scope from desktop computers. In particular, the demands of the specific application and the interface with external equipment may dominate the system design. Also, long life-cycles and in some cases extreme cost sensitivity require more attention to optimization based on these goals rather than maximizing the computational throughput.
The business and cultural climates in many embedded system design situations are such that traditional simulation-based computer design techniques may not be viable in their current form. Such methodologies may not be cost-effective given constraints on categories of expenditures, may not be seen as worthwhile by non-computer-trained professionals, or may simply be solving the wrong problems.
Recent interest in hardware/software codesign is a step in the right direction, as it permits tradeoffs between hardware and software that are critical for more cost-effective embedded systems. However, to be successful future tools may well need to increase scope even further to include life-cycle issues and business issues.
The tutorial slide presentation presented at the conference augments this paper, and may be found at: cs. cmu. edu/
Agradecimentos.
This work was sponsored, in part, by DARPA contract DABT63-95-C-0026, and ONR contract N00014-96-1-0202.
Referências.
[1] Bernard Cole, "Architectures overlap applications", Electronic Engineering Times , March 20, 1995, pp. 40,64-65.
[2] Stephanie White, Mack Alford & Julian Hotlzman, "Systems Engineering of Computer-Based Systems." In: Lawson (ed.), Proceedings 1994 Tutorial and Workshop on Systems Engineering of Computer-Based Systems , IEEE Computer Society, Los Alamitos CA, 1994, pp. 18-29.
[5] Daniel D. Gajski, Frank Vahid, Sanjiv Narayan & Jie Gong, Specification and Design of Embedded Systems , PTR Prentice Hall, Englewood Cliffs NJ, 1994.
[6] Jack Ganssle, Art of programming Embedded Systems , Academic Press, San Diego, 1992.
[7] Don Thomas & Rolf Ernst (eds.), Proceedings: Fourth International Workshop on Hardware/Software Co-Design , IEEE Computer Society, Los Alamitos CA, 1996.
[8] David Patterson & John Hennessy, Computer Architecture: a Quantitative Approach , Morgan Kaufmann, San Mateo CA, 1990.
[10] Shem-Tov Levi & Ashok Agrawala, Fault Tolerant System Design , McGraw-Hill, New York, 1994.
[11] Daniel Siewiorek & Robert Swarz, Reliable Computer Systems: design and evaluation (2nd edition) , Digital Press, Burlington MA, 1992.
[12] Nancy Leveson, Safeware: system safety and computers , Addison-Wesley, Reading MA, 1994.
[13] Georgette Demes et al. , "The Engineering Design Research Center of Carnegie Mellon University," Proceedings of the IEEE , 81 (1) 10-24, January 1993.

Embedded Communication.
Carnegie Mellon University.
18-849b Dependable Embedded Systems.
Author: Leo Rollins.
Communication is essential to achieving a dependable distributed embedded system. Designers of these systems are faced with several challenges in specifying the communication network. Complex systems usually require some sort of shared media network. In this environment, the designer must recognize the fundamental trade-off that exists between the efficiency and the predictability of the network. Given this trade-off, the designer must evaluate and select the communication network. Particular attention must be given to the protocols, which determine much of the network behavior. Finally, many error detection methods are available which are necessary to build a reliable communication system.
Tópicos relacionados:
Most historical communication systems can be considered to be "embedded" at least from one perspective: they have a very narrowly defined task. They are not designed for general purpose communication. For instance telephones were conceived for only for the purpose of voice transmission. However, this fact has been changing in recent years with the design of integrated services networks. These networks are designed to carry different types of communication including voice, data and video signals. Even systems with a single original purpose like telephony have been exploited for the transfer of other traffic, like data transfer for computers. Another development that has increased interest in general purpose communication is the internet. Once computers across the world began to be connected, the problem of incompatible networks became apparent. The OSI (Open Systems Interconnection) Reference Model was developed in an attempt to solve this compatibility problem. This model divides the communication system into seven layers which provide varying levels of service. The layers were intended to provide standard interfaces and services, so that various protocols, machines and network types could coexist.
Despite the spread of general purpose networking ideas, there are still many closed systems which have very specific purposes. In this environment, a simple and efficient protocol can be enforced without the danger of incompatibilities. An example is the network of devices in a modern automobile that communicate over a network. From the perspective of the author these narrowly defined closed systems are considered embedded communication systems. Even in these embedded systems, there is increasing interest in the connection of embedded systems to larger networks for status monitoring purposes. Just as the embedded systems have borrowed communication protocols and technology from larger communication systems, they are likely to borrow the many of the interconnection and standardization ideas in the near future.
The majority of embedded communication systems can be classified as either point-to-point networks (data links) or shared media networks (data highways). It is important to understand the trade-off between these two types of systems. In point-to-point networks, each node of the system is connected to every other node. These systems are simple and reliable. Reliability is high since correct transmission between two nodes only depends on a single transmitter and receiver. Since each link is dedicated to communication between two nodes, it is easy to meet real-time deadlines without any sophisticated scheduling mechanism. In shared media systems all nodes are connected together using a ring or bus topology. The primary motivation for shared media is the reduction in wiring (and thus cost). These networks are easily extendable without adding any new data ports to individual nodes. Limited new cabling is required.
The price for scalability and reduced cost of a shared media network is the complexity that must be added to the network protocol. Some means must be added to arbitrate for access to the shared media. The remaining discussion in this paper applies mainly to shared media embedded communication systems.
Event versus State Based Communication.
In practice communication systems may not be purely event or state based. A communication protocol may contain some properties of each. However, it is instructive to examine the fundamental differences between an event based system and a state based system. One of the fundamental trade-offs between these two types of systems is the efficient use of resources found in event based systems versus the predictablity of the network found in state based systems. The primary resources of concern in the network are bandwidth (the amount of data that can be transmitted per unit time) and the buffer space required at nodes to process incoming or outgoing messages.
In an event based communication system, messages are generated and transmitted in response to "events" detected at a local node in the network. Examples of "events" include changes in the value of process variables, new alarm conditions that have been detected, conditions that represent alarms clearing, or requests by other nodes for data. An example of an event based communication system is the typical office network. Messages are generated by users whenever they send data to printers, access data on shared network drives, run applications that exist on other machines or send email to others in the network.
One goal of event based communication is the efficient use of network bandwidth. By transmitting only necessary data, an efficient use of network bandwidth is assured. However, since data is transmitted only when there is a change at the source node, every message becomes important. This places additional requirements on the communication system to assure that each message is delivered successfully. One mechanism to do this is for destination nodes to acknowledge each successful transmission and request a retry for each corrupted message. If an acknowledgement is not generated within a specified timeout, the source node may also repeat the message of its own accord. Note that this acknowledge and retry mechanism consumes some additional network bandwidth.
Consider the example of an event based distributed monitoring system. This system monitors plant conditions and generates alarms when certain conditions are generated. During normal operation, the network should be lightly loaded with few alarm conditions. During system upsets, many messages will be required due to multiple alarm conditions and changing state. It is difficult to predict the maximum number of messages that might be exchanged during this situation. Many nodes may compete for the communication channel. Therefore it is difficult to confirm that a system design will contain adequate resources (bandwidth and buffers) to handle the load. For a system with safety functions, the network is at its worst (in terms of delay and lost messages) when it is needed the most. This condition is sometimes referred to as the alarm flood problem. One potential solution to this problem is to design an overly conservative network in order to meet the worst case situation. This approach may not be feasible in a small embedded system with cost constraints.
In a state based communication system, messages represent the entire state of a node. For instance, all of the alarms for a node are transmitted as either on or off in its message. A node sends its fixed size message at pre-defined, regular intervals. Access to the media is easily scheduled, since the message requirements of each node never change. Network load is fixed and can be easily calculated during system design. An example of a state based system is a distributed process control system. Each node has a fixed number of inputs, calculated values, and alarm conditions that it sends in its message to other nodes in the network.
The state based system is a less efficient in terms of network bandwidth than in the event based system. Network bandwidth is sacrificed for the predictability of regular message size and regular access to the communication channel. Note that some reduction in the overall data is possible. Each piece of data occupies a fixed location in the message. Therefore the data can be restricted to value. Information about what each data point represents is not required to be transmitted with the message.
State based systems can be designed to tolerate the occasional missed message. Re-transmission may not be necessary, since the entire state will be transmitted again in the next time interval. If messages are transmitted at twice the required frequency, the system can meet its deadlines even if every second message is corrupted. In order to tolerate two corrupted messages in a row, the each node could be designed to transmit its messages at three times the required frequency.
One difficulty in state based systems is transient data. It is important for a source node to maintain momentary signals for a sufficient duration that all nodes will see the data. Although the data persists for only a fraction of one message time, a source node may need to transmit the data in several successive messages. This momentary situation is sometimes referred to as the "pulse-stretching" problema. An example of transient data is a momentary push-button which is a hard-wired input to a single node. Assume that indications of button presses are needed at some other node in the system. If the condition that the button had been pushed was transmitted in only a single message, and that message was lost, other nodes would be informed that the button had been pressed.
Finding the Best Real-Time Protocol.
According to [Kopetz97] there has never been or will ever be a perfect real-time protocol. This is because there are fundamental conflicts in the requirements that we would like to place upon the communication system. These requirements are the best features of both event based and state based systems. The conflicts reflect trade-off between either the efficiency or flexibility found in the event-based system and the predictability found in the state-based system. Trade-offs exist for external control versus composability, flexibility versus error detection and protectiveness, sporadic data versus regular data, spontaneous service versus interface simplicity, and probabilistic access versus replica determinism. For a detailed discussion of each specific trade-off refer to [Kopetz97].
Even though no "best" protocol exists, embedded system designers are not relieved of the task of specifying an appropriate communication system. Therefore it is important to focus on the key differentiating factors found in the protocols. The OSI Reference Model, shown in Figure 1, can be used to examine communication protocols. A brief description of the function of each of the layers is provided below. For more information refer to [Spragins94]
Figure 1: OSI Reference Model Layer 7: Application - Provides standard interfaces for different types of data transfer such as mail or file transfer.
Layer 6: Presentation - Allows data to be presented to the application in the native format allowing communication between systems with different data representations.
Layer 5: Session - Provides a means for applications to structure a dialogue between each other.
Layer 4: Transport - Provides transparent transfer of data and end-to-end control of message transfer.
Layer 3: Network - Provides an abstraction from the particular communication technology used at lower layers. Includes the functions of routing and relaying messages within the network.
Layer 2: Data link - Provides the procedures for access to the channel, initiating and closing links between stations, grouping of characters into messages or frames, error control and frame synchronization.
Sublayer LLC - Logical Link control is concerned primarily with the establishment and termination of a virtual connection between two stations in a network. Sublayer MAC - Media Access Control is concerned primarily with arbitrating for and granting access to the communciaiton channel.
Layer 1: Physical - Provides the electrical or optical transmission characteristics and representation of signals. This layer also includes the procedures used to intiate or close communication on a physical link.
Embedded systems tend to focus on layer 1 (physical) and layer 2 (data link) and use minimal or non-existent upper layers. Two reasons for this focus may be 1) embedded communication systems are simple and do not require upper level services 2) upper layers add overhead that cannot be tolerated in some real-time systems. However this situation may change as complexity increases in embedded systems and users demand more features such as the interoperability with other networks. In order for multiple networks to communicate a common interface is needed. A common upper layer in the protocol may provide this interface.
Within the data link layer a sub-layer called media access control (MAC) exists which determines many of the characteristics of a shared media communication system. Several media access techniques have been proposed and successfully used in popular protocols. Some common media access techniques and protocols which use these techniques are covered below.
CSMA/CD - Carrier sense multiple access with collision detection. Each node monitors the channel or carrier to determine when the channel is idle. This is known as carrier sense. If the node has a message to send it begins transmission. The node continues to monitor the channel while it is transmitting. Another node in the network could also begin transmitting on the clear channel. In this case a collision would be detected by both nodes. The nodes would stop transmitting their messages and send a jam signal for a duration long enough for all nodes in the network to see the collision. Each nodes then computes and waits for a random interval before retrying its transmission. The Ethernet protocol used in office LANs (local area networks) popularized this access method. It was later standardized as IEEE 802.3.
CSMA/CA - Carrier sense multiple access with collison avoidance. Initial access to a clear channel is performed similiar to CSMA/CD. However, after a collision and a jam signal, stations use contention slots to resolve access to the channel. These slots give a node or nodes priority of access during its contention slot. Due to this priority contention slot, some collisions that would have occured on retries in CSMA/CD are avoided in CSMA/CA. The slots assignments are rotated between successive collisions to ensure fairness. An example of this protocol is LONWorks.
Polling - In polling, a single master node controls access to the channel. All other nodes are polled sequentially to determine if they have messages to send. If they have messages, they are granted access to send their messages. Note that this method relies heavily on correct operation of the master. Intel's BitBus and many fieldbus communication protocols use this method.
Bit Dominance - In bit dominance protocols, all nodes are synchronized. Each node begins transmission on a clear channel by sending its node or message ID. This ID indicates the priority of its transmission. The node with the highest ID wins the bidding because the 1's in its ID dominate any 0's sent by other nodes. Note that this requires an electrical media where sent 1's dominate over 0's. The Controller Area Network (CAN) based on this access method is used heavily in automobiles.
Token Passing - In token passing, access to the channel is determined by the holder of a token. When this node is finished transmitting, it passes the token in a special message to the next node in the network. If a node has no messages to send, it simply passes the token. Special bidding processes are often required to establish the initial holder of the token and how long each node may hold the token. IBM's token ring, token bus and FDDI (fiber distributed data interface) all use some form of token passing.
TDMA - Time division multiple access. In this access method, the bandwidth of the network is sliced into slots. Each node is allocated one or more slots where it has sole access to the channel. The slots repeat continuously, giving each node periodic access to the channel. ARINC 629 (Aeronautical Radio Incorporation) is a protocol established for embedded airplane networks that use this method. Another TDMA protocol designed specifically for fault tolerant real-time applications is TTP (time-triggered protocol). This protocol is a relatively recent development (1993) and its applications in real embedded systems are unknown to the author.
Individual protocol studies have been undertaken and published in journals. Unfortunately, only limited comparisons of the protocols used in embedded systems have been performed. Refer to [Koopman94] for a qualitative comparison of protocols used in embedded systems and more detailed coverage on individual media access techniques.
Although the protocols themselves are not strictly event or state based, they often lend themselves more easily to one or the other system type. For instance, CSMA/CD used in Ethernet is a probabilistic access method. Event based systems fit well with this protocol because of the sporadic nature of messages. Time division multiplexing protocols break up the network bandwidth into time slices for individual nodes. State based systems can efficiently use one or more time slices to send their regular data.
Error Detection / Diagnostics.
Error detection and diagnostics are important in any embedded system and especially in safety critical systems. Communication systems are fairly advanced in their capabilities for detecting, tolerating and sometimes correcting errors. In Table 1, some typical errors for communication systems are listed. Along with each error type, the typical defenses available in the communication system are discussed. Knowledge of common error types and defenses are invaluable to the system designer.
Channel noise - Noise is typically induced in communication channels from the environment or cross-talk from adjacent wires. A technique to reduce the noise is the use of fiber optics for the communication channel. Fibers are impervious to electro-magnetic interference. Cyclic redundancy checksums (CRC) are often appended to messages. These checksums allow the detection of all single and many multiple bit errors induced in messages. More sophisticated error coding techniques can also be used to correct bit errors.
Stale messages - Old messages that do no represent accurate real-time data may be present in the system. Some protocols include a time-stamp that is inserted by the source to mark the message age. Note that this implies some global time base.
Repeated messages - In certain failures of a host node or its network interface, the same message may be continuously repeated. Some protocols include a serial number for each message. Destination nodes can easily detect repeated or out of sequence messages.
Failure propagation - In a shared media system it is important to prevent failures in one node from propagating to other nodes. Surge protection is often included to prevent electrical failure propagation. Fiber optic cables serve as galvanic isolation between nodes. Redundant networks can also prevent propagation.
Station run-on - Stations may fail in such a way that they monopolize the shared media. Some protocols, such as Ethernet, contain an anti-jabber supervisory circuit. These circuits bound the time that any station is allowed access to the media. The station will be locked out until a specified silence period is observed.
Memory errors - Internal to a node, a message may be copied several times. Copies are typically made in DMA transactions or other exchanges between a host node and its network interface chipset. It is possible to add information checksums to messages that can be used to detect memory errors in the copy process.
Interface hardware failures - Communication interface hardware can fail. Diagnostics are included in many communication systems that allow loop-back testing of the interfaces.
Intermittent errors - Errors may begin to occur at a higher rate that is below the threshold for system errors. However, the increase in these errors may signal a bad part or connection in the system. Many communication chipsets include statistical counters that show error rates and types. If reported to the system level, these errors can signal maintenance action before system failures occur.
Cable breaks - The loss of communication through cable breaks is normally detectable through loss of signal. However, some communication systems include fault-tolerant capabilities that tolerate cable breaks. One example is FDDI, which is configured as counter rotating rings. Individual stations can reconfigure the rings to bypass the cable breaks.
Protocol Analyzers can be attached to most networks to examine data at the bit, character and frame level. Headers for common protocols can be automatically decoded. These analyzers are particularly useful in examining errors and violations of protocols.
Time domain reflectometers can analyze the cabling and connections in networks. Versions of this equipment exist for electrical and fiber optic media. They are useful in finding cable breaks, bad connections and determing cable lengths. These instruments work by sending a wave down a cable and examining the reflections. Each reflection represents a connection or impefection in the cable. In fiber optics, connection quality is extremely important. These instruments can determine the loss in signal level introduced by each connection.
Formal methods techniques have been applied to the verification of communication protocols (Petri Nets, Lotos, SDL, Z …). Petri Nets, in particular, were created to analyze communication networks. The verification of a protocol is normally required during the standardization process. Some level of correctness can be ensured by the embedded system designer if he chooses a standardized protocol.
A more likely effort for embedded system designers is the selection of a communication system. In order to do this, a good handle on the requirements and key issues involved in the decision is needed. A list of the issues and specific recommendations are presented in [Preckshot93] NUREG/CR-6082, Data Communication. This document was developed as a guide for regulatory authorities to use when evaluating proposed systems. Even though it is intended for the nuclear industry it is applicable to other embedded systems because it asks focused questions about the communication system.
The common metrics published in manufacturer's literature are data rate and error rates. Protocol studies give more detailed measures of the performance that may be expected. These studies involve complex modeling and simulation techniques. It is not surprising that large scale quantitative comparisons between many protocols have not been attempted. Examples of the metrics found in protocol studies are throughput versus load, delay versus throughput, and worst case utilization.
In general the communication theory and analysis techniques are quite mature. However, the process of selecting the communication system is ad hoc at best.
Communication may be considered as a form of I/O. However, a more applicable relationship may be the current trend to use field busses to communicate with I/O.
The communication architecture is often the method used for achieving a dependable embedded system, usually through redundancy.
Embedded communication systems are most often real-time systems. The real-time topic covers schedulability, which is important in shared media networks.
Communication enables fault tolerant computing through the use of error detection.
Error coding techniques are often used in communication for error detection, error correction, reliability, compression, and optimum signal-to-noise ratio.
Formal methods are often used for communication protocol verification.
A fundamental trade-off exists between efficiency and predictability in the selection of an event-based system or a state based system. Regardless of the decision, there are shortcomings that must be addressed. The lack of a detailed quantitative comparison of protocols places the burden of communication system evaluation squarely on the embedded system designer. Many of the properties of the communication system are determined by the media access protocol. Therefore, embedded system designers should focus on the media access method when determining what protocol to use. Other significant factors to consider include the communication technology and its cost or longevity. Often overlooked in design are the error conditions. Communication systems have a variety of mechanisms that can be used to detect errors. Utilizing these detection methods, the designer can build a reliable communication system.
[Koopman94] Koopman, P. J., and Upender, B. P, "Communication Protocols for Embedded Systems", Embedded Systems Programming, 7(11), November 1994, pp. 46-48, cs. cmu. edu/People/koopman/protsrvy/protsrvy. html, Accessed: May 8, 1999.
Notes: Good qualitative comparison of protocols, especially the variety of available media access methods. Prático. Written at an introductory level. Examines different media access methods in some detail.
[Kopetz97] Kopetz, H., Real-Time Systems, Design Principles for Distributed Embedded Applications, Klower Academic Publishers, 1997, Chpt.7-8.
Notes: Wide variety of information on real-time systems. A key discussion examines five fundamental trade-offs in the ideal requirements of communication systems. Communication section show bias towards the Time Triggerd Protocol (TTP) which he has written other papers about.
Notes: Written from an safety system assessor's viewpoint for critical systems. However, this document asks all the questions an embedded system designer should ask himself. The appendix is more tutorial in nature.
[Spragins94] Spragins, J. D., Hammond, J. L., and Pawlikowski, K., Telecommunications Protocols and Design, Addison Wesley Publishing, 1994.
Notes: Good source for mathematics of communication, queuing theory, and metrics. Unfortunately, the examples covered are standard communication protocols rather than embedded system protocols. This reference also provides a good background on the OSI Reference Model and communication networks in general.
Leitura adicional.
[Norden98] Norden, S., Manimaran, G., Siva Ram Murthy, C., "New Protocols for Hard Real-Time Communication in the Switched LAN Environment", Proceedings - 23rd International Conference on Local Computer Networks, IEEE Computer Society, 1998, pp. 364-373.
Notes: The discussion is more tailored to using existing telecom networks. Not so applicable to embedded systems. This may be a future issue. Does cover the issue of QOS and mixing of traffic types.
[Paige90] Paige, Lt. J. L., "SAFENET - A Navy approach to Computer Networking", Proceedings - 15th International Conference on Local Computer Networks, IEEE Computer Society, 1990, pp. 268-273.
Notes: High level architecture of two safety critical communication systems. One is based on Ethernet, the other on FDDI.
Notes: Tries to predict if Ethernet will spread to factory floor. May be too opinionated. Not very strong in supporting arguments. May have hidden agenda, since it is on his employer's web site.
[Raman90] Ramanathan, P., Shin, K. G., Butler R. W., "Fault-Tolerant Clock Synchronization in Distributed Systems", IEEE Computer, 23(10), 1990, pp. 33-42.
Notes: This is big issue for some protocols like TDMA (and for some applications that require sequence-of-events). Gets into the Byzantine General's problem for synchronization in the presence of faulty clocks. There are lots of papers about this issue. [Kopetz97] has one also.
[Scholl88] Scholl, F. W. and Coden, M. H., "Passive Optical Star Systems for Fiber Optic Local Area Networks", IEEE Transactions on Selected Areas in Communications, 6(6), 1988, pp.913-923.
Notes: Good idea because the network connection is passive and therefore more reliable. Unfortunately, this method may not be supported by current technology. High losses in stars only work with strong transmitters. Ok in early days when fiber optic transmitters were high power. Now most transmitters are LEDs with lower power output.
[Upender97] Upender, B. P. and Dean, A., "Embedded Communication Network Pitfalls", Embedded Systems Programming, 10(9), 1997, embedded/97/fe29709.htm, Accessed: May 8, 1999.
Notes: Analysis of the problems with protocols for certain applications, but only covers 3 (LonTalk, CAN and IEEE-1394).
[Zhao95] Zhao, W. and Malcolm N., "Hard Real-Time Communication in Multiple-Access Networks", Real Time Systems, 8, 1995, pp.35-77.
Notes: In depth analysis of MAC types. Tends toward mathematical.

Trade-off in embedded systems

O portal Infona usa cookies, ou seja, cadeias de texto salvas por um navegador no dispositivo do usuário. O portal pode acessar esses arquivos e usá-los para lembrar os dados do usuário, como as configurações escolhidas (exibição de tela, idioma da interface, etc.) ou seus dados de login. Ao usar o portal Infona, o usuário aceita a gravação automática e o uso dessas informações para fins de operação do portal. Mais informações sobre o assunto podem ser encontradas na Política de Privacidade e nos Termos de Serviço. Ao fechar esta janela, o usuário confirma que leram as informações sobre o uso de cookies e aceitam a política de privacidade e a forma como os cookies são usados ​​pelo portal. Você pode alterar as configurações de cookies no seu navegador.
INFONA - portal de comunicação científica.
Abstrato.
Identificadores.
Atribuição do usuário.
Atribuição remova a confirmação.
Você vai remover essa tarefa. Você tem certeza?
Sch. of Comput. Sci. & amp; Technol., Xidian Univ., Xi'an, China.
Yingfeng Wang.
Sch. of Comput. Sci. & amp; Technol., Xidian Univ., Xi'an, China.
Zhijing Liu.
Sch. of Comput. Sci. & amp; Technol., Xidian Univ., Xi'an, China.
Informação adicional.
Compartilhar.
Exportar para bibliografia.
Relatar um erro / abuso.
Enviando o relatório falhou.
Enviando o relatório falhou. Por favor, tente novamente. Se o erro persistir, entre em contato com o administrador, escrevendo para support@infona. pl.
Opções de acessibilidade.
Você pode ajustar o tamanho da fonte pressionando uma combinação de teclas:
Você pode alterar os elementos ativos na página (botões e links) pressionando uma combinação de teclas:
TAB vá para o próximo elemento SHIFT + TAB ir para o elemento anterior.

Embedded Use.
HMIs for Embedded Devices.
Why Use Qt for Embedded Systems.
When my customers develop embedded systems, they face similar challenges:
Challenge 1: iPhone-Like HMI Challenge 2: Internet-Connected Challenge 3: Running Everywhere Challenge 4: Fast Time-To-Market.
Using examples from different industries, I’ll first elaborate on the challenges and then on how Qt can help us to solve these challenges. These challenges are typical for nearly every industry nowadays: automotive, agricultural, medical, manufacturing, home-appliance, home-automation – to name just a few.
Challenge 1: iPhone-Like HMI.
Challenge Explained.
Requirement specifications for HMIs have become pretty short these days: “My HMI shall look, feel and behave like an iPhone”. Mas & # 8211; what does it mean for an HMI to be iPhone-like? I think that Larry Constantine’s five rules to characterise good usability give the best definition of “iPhone-like” (Note: I summarised Constantine’s rules 1, 2 and 3 into my rule 1):
Rule 1: HMI adapts easily to different experience levels (beginner, intermediate, expert). Rule 2: HMI is suited for the context, in which it is used. Rule 3: HMI makes real work easier, faster, more fun, or makes new things possible.
My simple washing machine has a strictly mechanical HMI: a rotary button, a few push buttons, no display. I have three types of laundry: the stinky stuff (underwear, towels, etc.), the normal stuff (shirts, good pants, etc.) and the special stuff (some woollen sweaters). For each type, I have to set the buttons again and again. There is no way to define a programme for each type. So, my simple washing machine fails Rule 1, as it is no good for intermediate or expert use.
A good example for Rule 2 are the different ways of user input for an in-vehicle infotainment system. Entering a destination is pretty tedious with a rotary knob, but pretty simple with touch. In contrast, changing the settings of the climate control is simpler and especially less distracting with the rotary knob than with touch. With touch input, the driver must look at the screen. With a rotary knob, the driver can do the change without looking. The simplest way of all is speech control, which fits the context of driving a car best.
Getting Rule 3 right is what made the iPhone such a success. Browsing through photos in cover flow with a simple flick of our finger is obviously easy, fast and fun. Everyone grasps the idea intuitively and gets grumpy when they have to browse photos in the old way. Another example for Rule 3 is navigation. By simply adding a GPS antenna to a smartphone, it became possible to use the smartphone as a sat nav – and save some money on buying a separate sat nav.
These three rules are a good guideline to tell apart a good and a bad HMI. They also give a pretty clear idea what customers mean when they want an “iPhone-like user experience”.
Solution with Qt.
Of course, the first step towards an iPhone-like user experience is a really good user interaction design. For the next step, the implementation of this design, we need a technology that makes it easy and quick to turn a great design into a great HMI of our embedded system. Enter QML!
QML is a lightweight declarative language built on top Qt. It is very easy to learn and leads to very compact code. In the early days of QML, I was tasked by a premium TV maker to rewrite a prototype of their TV GUI in QML. They needed 20 days and 18K lines of code to write the original prototype. The QML version took me only 5 days and 1.5K lines of code. And bonus, the QML version ran much faster and smoother on their TV hardware.
QML enables a pair of a UI designer and an application developer to develop a GUI very quickly in a very agile way. The design gets implemented almost instantly and tried out immediately on the target hardware. The pair can even ask some users to try out a feature. Based on the users’ feedback, the GUI is changed – often on the spot. Knowing early what works and seeing alternatives is very valuable to customers. QMLs support for an agile approach (very much in the sense of eXtreme Programming) makes it easy to satisfy the three golden rules of good usability.
QtCreator – a first-class IDE for developing software with QML, Qt and C++ – includes a UI designer (tool) for QML. So, it supports the work of both the UI designer (person) and the application developer very well. If this is not enough, QtCreator can be customised to special needs, as it is open-source and is implemented using a plugin architecture.
Here are a few examples of systems using QML for their GUIs: Blackberry 10 smartphones, in-vehicle infotainment (IVI) system of QNX’s concept car for CES 2017, IVI systems of three car OEMs (soon to be on the roads), Freebox set-top box (STB) by French telco Free, millions STBs and TVs, Loewe’s SoundVision system, in-flight entertainment systems of 50+ airlines, home appliances of several top-10 OEMs and many more systems. If you are still not convinced about the simplicity and power of QML, read KDAB’s post “Qt 5 under the hood”. It is a fantastic testimony by QNX how easy and fast it was to develop the in-vehicle infotainment system of QNX’s concept car for CES 2017. It says it all!
Challenge 2: Internet-Connected.
Challenge Explained.
If we hook up our home appliances to the Internet, new things become possible (Rule 3 from above). The oven can send an alert to our smartphone when the bread is ready. So, we can watch TV in another room without the bread getting burned. When our washing machine is defect, it can prepare a diagnostics report, which we can send to the technical support of the manufacturer. The technical support could even log into our washing machine to find out what’s wrong. Or, we can control our wireless speakers from our induction hob such that we can listen to Internet radio stations or our own music. There seem to be nearly limitless possibilities once a device is connected to the Internet.
Solution with Qt.
Qt supports the application layer protocols like HTTP, TLS/SSL, FTP and DNS right out of the box – even through proxy servers. This is easily enough to use web services over RESTful APIs. If we need other application layer protocols, say, like SIP, RPC or POP3, we can implement them using Qt’s TCP and UDP socket classes. We can also use these socket classes to implement proprietary protocols. More often than not, we’ll find out that someone else has implemented a communication stack with Qt already. There are stacks for SIP, VoIP, SOAP and many others. So, Qt has all that’s needed to connect our embedded systems to the Internet.
Challenge 3: Running Everywhere.
Challenge Explained.
Users can nowadays control their home appliances from their smartphones, tablets and PCs – in addition to controlling them directly from, say, a touch screen. Hence, similar HMI software must run on different smartphone and tablet OSs (iOS, Android, Windows Phone, etc.), on different desktop OSs (Windows 7/8, Mac OS X, Linux), and on the OS of the embedded system (Linux, QNX, vxWorks, etc.). On top of that, the OS must run on different processor architectures (ARM, Intel, SH4, MIPS, etc.) – with different means of graphics acceleration (OpenGL, OpenVG, DirectFB, none).
Of course, we do not want to develop the same HMI software for each mobile, desktop and embedded OS over and over again. That would multiply our development efforts. Hence, we want to reuse as much code as possible. And, we do not want to care on which OS and processor architecture our system will run in the end.
Solution with Qt.
There are two technologies that run everywhere: Web (HTML, JavaScript, CSS, etc.) and Qt. Especially on resource-restricted systems like embedded systems and smartphones, Web is not a serious contender. It is far too resource hungry with respect to memory, speed and power. Consequently, the user experience is not at all iPhone-like. Yes, that is exactly the reason why the HTML5 apps of Facebook and Google Maps were replaced by native apps on iOS and why the Palm Pre failed so miserably.
This leaves Qt as the last man standing when it comes to technologies running everywhere with near-native performance. Qt runs on all desktop operating systems (Windows XP/7/8, Mac OS X, Linux), on all relevant mobile operating systems (iOS, Android, Blackberry, Windows Phone) and on most embedded operating systems (Linux Embedded, Windows Embedded, QNX, vxWorks, Nucleos, Integrity). And, it runs at near-native performance. Qt makes a much better trade-off between being cross-platform and running at native performance than Web.
Once developed, we can run our system on every relevant mobile, desktop and embedded operating system. This is in stark contrast with developing the system for every operating systems natively and separately – using different technologies on these systems. Qt will save us a lot of development and allows us to bring our products to the market faster.
Challenge 4: Fast Time-To-Market.
Challenge Explained.
Volkswagen has nine brands including VW, Audi, Seat, Skoda and Porsche. Every brand has many different models (Up, Polo, Golf, Passat, Tiguan, Caddy, etc.) for different categories (supermini, compact, family, premium, SUV, etc.). Volkswagen sells its cars in nearly every country of the world (150+ countries), which requires localisations to the special regulations and user requirements of these wishes.
That is a lot of complexity, Volkswagen and other car makers have to cope with. And, they have to release their cars to market in ever shorter cycles. When it comes to hardware like the car body, engine, power train, seats or dashboard, they have figured it out pretty well. They use the same parts in cars of different brands addressing similar market segments. In short, car makers use a platform concept.
When it comes to software like in-vehicle infotainment (IVI) systems, car makers have failed miserably. Different brands use different suppliers to build their IVI systems. Even worse, car makers use different suppliers for the same brand. Every time car makers changes their supplier, they change to a completely different IVI system. The situation is not much better with makers of home appliance or agricultural machines. What a waste of time and money!
Solution with Qt.
What all these OEMs need, is a proper software platform! The platform must enable the OEMs to adapt their GUIs easily to the look, feel and behaviour of different brands, models, categories and countries. It must also enable them to run their system on different hardware platforms and operating systems. Essentially, the platform must enable the OEM to become independent of the supplier and change suppliers easily.
The platform provides APIs for functional areas like vehicle data, multimedia, radio, connectivity, navigation, window management, configuration management and diagnostics. These APIs constitute a software application layer, which makes the GUI of the IVI system independent of the actual software used for these areas. For example, the GUI doesn’t have to worry about, whether multimedia functionality is implemented with the GStreamer or Cinemo multimedia stack. On different hardware platforms, the multimedia API can even be implemented by different stacks.
Qt is ideally suited for this kind of abstraction, because it provides many of these APIs already like APIs for multimedia, connectivity and window management. Furthermore, Qt is all about cross-platform APIs that abstract away the actual implementations. If some APIs are missing in Qt, we can easily extend Qt. For our car OEM, we would provide a base SDK (software development kit), which serves as the base platform for all of its cars. There may be special SDKs, built on top of the base SDK, for different car categories or models.
These SDKs make it easy for the application developers to implement the HMI of the IVI system. These developers can work on their PCs and then try out their work on the actual hardware – right from the beginning of the project. Thanks to the SDKs, they don’t have to know on which platform they are running their software. Of course, the SDK also provides a library of standard widgets specific to the brand and the model.
This leaves us with the problem that the GUI of the IVI system must adapt easily to different brands, car models, car categories, countries, screen sizes and screen resolutions. Dealing with all these variants is where QML shines. As long as the layout of the GUI stays pretty much the same, we can handle this with themes (simple changes like colours, images, fonts, sounds, etc.). If the layout changes drastically, we must resort to skins, where we must rewrite parts of the GUI. In both cases, Qt’s file selectors will be of great help to manage all the different variants of the GUI.
Initially, the effort to build such a platform is higher than building just an IVI system. But the costs will quickly amortise – at the latest when the OEM changes a supplier or uses different suppliers for different brands. Personally, I know of three car OEMs that are building such platforms with Qt to be faster to the market. Unfortunately, they don’t want to be name at the moment.