Sistema De Comunicações Tolerante A Falhas E De Baixa .

3y ago
40 Views
2 Downloads
5.13 MB
89 Pages
Last View : 13d ago
Last Download : 3m ago
Upload by : Lucca Devoe
Transcription

FACULDADE DE E NGENHARIA DA U NIVERSIDADE DO P ORTOSistema de Comunicações Tolerante aFalhas e de Baixa Complexidade paraum Veículo EléctricoBruno Laranjo dos SantosMestrado Integrado em Engenharia Electrotécnica e de ComputadoresOrientador: Paulo José Lopes Machado Portugal (Professor Doutor)Julho de 2012

c Bruno Laranjo dos Santos, 2012

ResumoEsta dissertação propõe uma plataforma de hardware e software para o futuro desenvolvimentode aplicações de controlo por parte dos alunos do MIEEC (Mestrado Integrado em EngenhariaEletrotécnica e de Computadores) no VEC (Veículo Elétrico de Competição) da FEUP (Faculdadede Engenharia da Universidade do Porto). Neste sentido, propõe um sistema de comunicaçãotolerante a falhas e de baixa complexidade em que seja possível a troca de mensagens seguros narede.O mecanismo de acesso ao meio consiste num TDMA (Time Division Multiple Access), como uso de barramento redundantes. Este mecanismo utiliza um microcontrolador com 2 módulosCAN.Os dados a enviar são escalonados nas mensagens na fase de projeto, sendo as mensagenstrocadas entre nodos dentro do ciclo TDMA. Este mecanismo de acesso ao meio tolerante a falhas é completado com a implementação de uma safety layer de comunicação para o aumento daconfiabilidade das mensagens trocadas na rede.A implementação das soluções de comunicação é feita no RTOS (Real Time Operating System) Erika Enterprise & RT Druid do tipo OSEK/VDX (Open Systems and their Interfaces forthe Electronics in Motor Vehicles) da marca Evidence. Na aplicação implementada no RTOS, épossível trocar mensagens com o uso do mecanismo de acesso ao meio TDMA.Palavras chave - Comunicações, veículos, CAN (Controller Area Network), TDMA (TimeDivision Multiple Access), safety layer, Sistema operativo tempo real, OSEK/VDX, AUTOSAR(Automotive Open System ARchitecture).i

ii

AbstractThis thesis introduces a hardware and software platform for the future development of controlapplications from MIEEC (Master in Electrical and Computer Engineering) students in FEUP(Faculty of Engineering, University of Porto) VEC’s (Electric Vehicle Competition) . It presentsthe development of a low complexity and fault-tolerant communication system as it is possible toexchange reliable data in the network.It’s used a TDMA media access mechanism, using redundant bus with two modules CAN in amicrocontroller.The data are scheduled to the messages in the design phase and these are exchanged betweennodes inside of TDMA cycle. This fault tolerant media access mechanism is completed with theimplementation of a safety communication layer in order to increase the reliability of the messagesexchanged in the network.The implementation of communication solutions is performed in OSEK / VDX RTOS ErikaEnterprise & RT Druid brand by Evidence. It is possible to exchange messages using the TDMAredundant media access mechanism with the application implemented on the RTOS.Keywords - Comunication, vehicles, CAN (Controller Area Network), TDMA (Time DivisionMultiple Access), safety layer, Real Time Operating System, OSEK/VDX, AUTOSAR (Automotive Open System ARchitecture).iii

iv

AgradecimentosGostaria de agradecer,Ao Professor Paulo Portugal, pela motivação, a enorme ajuda no desenvolvimento desta dissertação.Ao meus pais João e Judite e ao meu irmão Alexandre, pelo carinho, motivação e a mais quepreciosa ajuda por esses vinte e quatro anos de vida ao vosso lado.Ao meu avô Joaquim, dos Homens a quem eu quero dedicar este documento.À Élia, pelos momentos ao meu lado, pela grande paciência, pelo carinho e pela grande ajudanos momentos menos bons.À todos os meus amigos, em especial ao André Gonçalves, ao Diogo Varajão e ao Tiago Bastos, pelas ideias partilhadas e pelas coisas que não se enquadram no contexto académico.Bruno Laranjo dos Santosv

vi

“If we all did the things we are really capable of doing,we would literally astound ourselves”Thomas Alva Edisonvii

viii

Conteúdo1Introdução1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.3 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Enquadramento2.1 Introdução . . . . . . . . . . . . . . . .2.2 X by Wire(XBW) . . . . . . . . . . . .2.2.1 Brake by Wire (BBW) . . . . .2.2.2 Arquiteturas Brake by Wire . . .2.3 Rede de Comunicação . . . . . . . . .2.3.1 Introdução . . . . . . . . . . .2.3.2 CAN . . . . . . . . . . . . . .2.3.3 TT-CAN . . . . . . . . . . . .2.3.4 FTT-CAN . . . . . . . . . . . .2.4 Gestão das aplicações . . . . . . . . . .2.4.1 Introdução . . . . . . . . . . .2.4.2 Sistema Operativo Tempo Real .2.4.3 OSEK/VDX . . . . . . . . . .2.4.4 AUTOSAR . . . . . . . . . . .341122.5568912131417192121212227Proposta3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . .3.2 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.3 Mecanismo de envio de mensagens tolerante a falhas . . . .3.3.1 Limitação do protocolo CAN . . . . . . . . . . . . .3.3.2 Solução do Time Triggered Redundante CAN . . . .3.3.3 Safety-Layer . . . . . . . . . . . . . . . . . . . . .3.3.4 Formato da mensagem . . . . . . . . . . . . . . . .3.4 Sistema Operativo Tempo Real . . . . . . . . . . . . . . . .3.4.1 Implementações de Sistemas Operativos Tempo Real3.4.2 RTOS escolhido . . . . . . . . . . . . . . . . . . .3.5 Plataforma de hardware . . . . . . . . . . . . . . . . . . . .313131323335374244444546Implementação4.1 A estrutura do RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.1.1 O Ficheiro OIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.2 Descrição da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49494952ix.

xCONTEÚDO4.3.535354545960Conclusões5.1 Conclusões da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.2 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .636364A CódigoA.1 Exemplo ficheiro tipo OIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6565Referências694.45Estrutura da Aplicação . . . . . . . . . . . .4.3.1 Tarefas de Comunicação e Supervisão4.3.2 Hierarquia de Tarefas da Aplicação .4.3.3 Subaplicação de comunicação . . . .4.3.4 Subaplicação de supervisão . . . . .Teste da Implementação . . . . . . . . . . .

Lista de 2.142.152.162.17Diferenças entre um sistema tradicional (esquerda) e um sistema drive by wire(direita) [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Esquema básico de um sistema drive by wire [2] . . . . . . . . . . . . . . . . . .Esquema da arquitetura proposta em [3] . . . . . . . . . . . . . . . . . . . . . .Esquema básico de um sistema Fail Operational Unit com duas fail-silent units [3]Esquema da arquitetura proposta em [2] . . . . . . . . . . . . . . . . . . . . . .Esquema da arquitetura proposta em [4] . . . . . . . . . . . . . . . . . . . . . .Formato da trama básica CAN [5] . . . . . . . . . . . . . . . . . . . . . . . . .Esquema do acesso ao meio em barramentos CAN [6] . . . . . . . . . . . . . . .Maquina de estados de erros em CAN [6] . . . . . . . . . . . . . . . . . . . . .Descrição de uma Transmition Column [7] . . . . . . . . . . . . . . . . . . . . .Descrição do Ciclo Principal no TT-CAN [7] . . . . . . . . . . . . . . . . . . .Exemplo de funcionamento do TM [8] . . . . . . . . . . . . . . . . . . . . . . .Exemplo de um ciclo elementar; [8] . . . . . . . . . . . . . . . . . . . . . . . .Diagrama de uma aplicação OSEK num microcontrolador [9] . . . . . . . . . . .Diagrama de estado das Tarefas em OSEK (adaptado de [9]) . . . . . . . . . . .Esquema de gestão das Tarefas em OSEK [9] . . . . . . . . . . . . . . . . . . .Divisão por camadas do software do AUTOSAR [10] . . . . . . . . . . . . . . 63.73.83.9Esquema geral da proposta da solução . . . . . . . . . . . . . . . . . . . .Inconsistência na recepção dos dados no CAN [11] . . . . . . . . . . . . .Principio do ciclo TDMA (adaptado de [12]) . . . . . . . . . . . . . . . . .Esquema geral do mecanismo de Transmissão da solução (adaptado de [12])Esquema da Transmissão proposto (adaptado de [12]) . . . . . . . . . . . .Esquema da Recepção proposto (adaptado de [12]) . . . . . . . . . . . . .Formato da trama do protocolo de segurança critica . . . . . . . . . . . . .Gráfico comparativo de diversos algoritmos de CRC de 8 bits [13] . . . . .Esquema do microcontrolador proposto [14] . . . . . . . . . . . . . . . . utura geral dos elementos necessários para uma aplicação (adaptado de [15])Mecanismo de envio e recepção de mensagens . . . . . . . . . . . . . . . . . . .Disposição dos SUBAPP na implementação . . . . . . . . . . . . . . . . . . . .Hierarquia de Tarefas da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . .Disposição da componente de transmissão da SUBAPP de Comunicação . . . . .Disposição da componente de recepção da SUBAPP de Comunicação . . . . . .Tarefa de recepção das mensagens CAN . . . . . . . . . . . . . . . . . . . . . .Disposição da componente da SUBAPP de Supervisão . . . . . . . . . . . . . .Esquema simplificado de ligação dos dois microcontroladores . . . . . . . . . .505253555657585960xi.

xiiLISTA DE FIGURAS4.10 Fotografia do circuito de desenvolvimento . . . . . . . . . . . . . . . . . . . . .61

Lista de Tabelas2.12.2Formato das tramas básicas no CAN . . . . . . . . . . . . . . . . . . . . . . . .Transição entre tarefas no OSEK/VDX [9] . . . . . . . . . . . . . . . . . . . . .3.13.2Relação entre os possíveis riscos e as ameaças para a rede [16] . . . . . . . . . . 40Relação entre as ameaças cobertas com as medidas propostas pela norma EN 50159 414.14.24.3Tarefas utilizadas na aplicação de comunicação . . . . . . . . . . . . . . . . . .Atribuição dos identificadores aos tipos de mensagem . . . . . . . . . . . . . . .Testes da implementação e seus resultados . . . . . . . . . . . . . . . . . . . . .xiii1425545861

xivLISTA DE TABELAS

Abreviaturas e EIDEISOISRMCMIEECOSEK/VDXPCBPSAAutomatic Cruise ControlAnti-lock Braking SystemAnalógico/DigitalAutomotive Open System ArchitectureApplication Programming InterfaceBrake AssistantBasic CycleBrake by WireBrake Pedal Input UnitController Area NetworkCyclic Redundant CodeCarrier Sense Multiple AccessCarrier Sense Multiple Access/Bus ArbitrationCentral Processing UnitDigital/AnalógicoData Lenght CodeElementar CycleEuropean StandardsElectronic Control UnitEnd Of FrameElectronic Stability ProgramFaculdade de Engenharia da Universidade do PortoFrame Sequence CheckFail Operational UnitFlexible Time-Trigerred Controller Area NetworkGeneral Public LicenseIntegrated Development EnvironmentIDentifier ExtensionInternational Organization for StandardizationInterrupt Service RoutineMaster CycleMestrado Integrado em Engenharia Electrotécnica e de ComputadoresOpen Systems and their Interfaces for the Electronics in Motor VehiclesPrinted Circuit BoardPeugeot Société Anonymexv

WABREVIATURAS E SÍMBOLOSRemote FrameReal Time Operating SystemRemote Transmition RequestStart of FrameSynchronous Requirement TableSynchronous WindowTransmition ColumnTraction Control SystemTime Division Multiple AccessTriggered MessageTriple Modular RedundancyTime-Triggered Controler Area NetworkTime-Triggered ProtocolVeículo Elétrico de Competiçãox by wire

Capítulo 1IntroduçãoNeste capítulo faz-se a introdução ao trabalho desenvolvido no âmbito desta dissertação. Éapresentada a motivação para o desenvolvimento deste trabalho. Em seguida, listam-se os objetivos que se pretende atingir com o trabalho da dissertação. Por fim, é exposto a estrutura destedocumento.1.1MotivaçãoA eletrónica automóvel tem tido um grande crescimento nos últimos anos, e como tal, temsido cada vez mais incluída nos sistemas de controlo. Alguns exemplos resultantes dessa evoluçãosão: o sistema de airbag, os sensores de auxílio ao estacionamento, os vidros elétricos, o sistemade limpa-vidros automático, o powertrain e o brake by wire.A FEUP atenta ao desenvolvimento da electrónica automóvel, criou o laboratório de electrónica automóvel numa parceria entre o departamento de engenharia eletrotécnica e o departamentode engenharia mecânica. Esse laboratório tem diversos projetos associados a conversão de veículos térmicos convencionais em veículos elétricos. O VEC (Veículo Electrico de Competição)corresponde a um desses projetos, trata-se de um veículo elétrico para uso em competições. Oveículo baseia-se no chassi do Fiat Uno 45 S, onde está a ser desenvolvido diversas aplicaçõespelos alunos do MIEEC.No desenvolvimento das diversas aplicações de controlo rapidamente começaram a surgir problemas de compatibilidade entre os diversos módulos. Na altura dos sistemas interagir entre eles,surgiam problemas de compatibilidade ao nível do hardware, software, e dos meios de comunicação entre os diversos sistemas impossibilitando o pleno funcionamento do veículo.À vista dos problemas referidas acima, a necessidade de criar uma plataforma unificada basepara os diversos sistemas de controlo presentes no veiculo automóvel elétrico começou a tornar-secrucial para o desenvolvimento de aplicações robustas.Os sistemas de controlo a implementar no veiculo, sendo sistemas que devem garantir umcerto nível de integridade, devem ser fortemente tolerantes a falhas, de forma a evitar ocorrência1

2Introduçãode avarias. As falhas, quando ocorrem, podem vir a prejudicar fortemente os sistemas, podendose propagar pelo sistema, originando uma perda total da funcionalidade do sistema. Os sistemastolerantes a falhas suportam normalmente um certo números de falhas antes da ocorrência de avariae consequente perda de funcionalidade. O número de falhas que um sistema suporta quantifica atolerância a falhas do mesmo.As comunicações dos sistemas de controlo devem obedecer às propriedades de tolerância afalhas e de segurança crítica na troca de mensagens. Esses dois mecanismos, em conjunto, devemgarantir que a mensagem enviada pelo nodo chega ao destino dentro dos requisitos temporais dosistema e que as mensagens sejam validadas como confiáveis para o seu uso pelo sistema.Outra componente de grande importância no desenvolvimento de sistemas distribuídos, consiste na gestão dos diversos componentes que constituem a aplicação de software. O uso demétodos padronizados de desenvolvimento de software para as unidades de controlo tornou-seinevitável, devido ao aumento crescente da complexidade das aplicações a desenvolver. Essa sistematização do desenvolvimento diminui o tempo de projeto das aplicações, pois são eliminadosdesenvolvimentos de interfaces inter-componentes usadas nas arquiteturas.1.2ObjetivosO objetivo da dissertação consiste na proposta e implementação de uma arquitetura de comunicação tolerante a falhas e de baixa complexidade, com a possibilidade da troca de mensagens seguras na rede. Esta plataforma servirá como sistema base para futuro suporte no desenvolvimentode aplicações de controlo por parte dos alunos do MIEEC (Mestrado Integrado em EngenhariaEletrotécnica e de Computadores) da FEUP (Faculdade de Engenharia da Universidade do Porto).As aplicações desenvolvidas pelos alunos do MIEEC têm como principal obejectivo a sua integração no VEC (Veículo Elétrico de Competição) do departamento de Engenharia Eletrotécnica daFEUP.A arquitetura proposta oferece flexibilidade para ligar diversos nodos, que trocam dados entresi por meio de um mecanismo de acesso ao meio TDMA (Time Division Multiple Access) com baseno protocolo CAN (Controller Área Network) e o uso de barramentos redundantes. A arquiteturade comunicação inclui ainda uma camada de segurança das comunicações, de forma a garantir aconfiabilidade dos dados trocados .Com o objetivo de se adequar ao perfil de conhecimento técnico dos alunos, o sistema de comunicação foi integrado num RTOS do tipo OSEK/VDX (Open Systems and Their Interfaces forthe Electronics in Motor Vehicles). O OSEK/VDX é um sistema operativo de baixa complexidadeadaptado às aplicações de controlo a desenvolver nos veículos.1.3Estrutura do DocumentoO documento da dissertação encontra-se dividido em 5 capítulos, explicitados em seguida:

1.3 Estrutura do Documento3O primeiro e presente capítulo apresenta a motivação e enquadramento súmario do trabalho,seguindo-se os objetivos, sendo no fim efetuado um resumo da estrutura do documento.O segundo capítulo é dedicado ao enquadramento mais promenorizado dos conceitos associados a este trabalho. Inicialmente é feita uma apresentação das arquiteturas de comunicaçãodos sistemas x by wire. Em seguida, são introduzidos os conceitos do protocolo de comunicaçãoCAN, incluindo o TT-CAN (Time-Triggered Controler Area Network) e o FTT-CAN (FlexibleTime-Trigerred Controller Area Network). No término do capítulo, são descritos dois standardsde gestão de aplicações, o OSEK/VDX e o AUTOSAR (Automotive Open System Architecture).O terceiro capítulo é dedicado à apresentação da proposta de implementação para o sistema decomunicação tolerante a falhas e à escolha do sistema de gestão de aplicação utilizado.O quarto capítulo apresenta a implementação da aplicação de gestão de comunicação, focalizandose na integração de todas as soluções propostas no capítulo anterior.O quinto capítulo está reservado para as conclusões do trabalho, onde é feito um resumocrítico do trabalho desenvolvido, apontando sugestões para o trabalho futuro que possa melhorara plataforma.

4Introdução

Capítulo 2EnquadramentoNeste capítulo pretende-se fazer uma revisão dos sistemas de comunicação tolerante a falhaspara aplicações de segurança crítica no veículo. Devido à existência de muitos sistemas de comunicações no veículo, foi utilizado como exemplo o sistema de travagem, sendo uma aplicação desegurança crítica relevante. Serão primeiramente apresentados neste capítulo os tipos de arquiteturas mais usados nos sistemas de comunicação tolerante a falhas. Posteriormente, serão descritosos protocolos usados na troca dos dados. No final do capítulo, serão descritas algumas metodologias de desenvolvimento de aplicações no veículo, descrevendo o conceito de sistema operativotempo real para microcontroladores.Todos os itens referidos acima são descritos com mais pormenor para que se possa ter conhecimento dos desenvolvimentos existentes nas diversas áreas, sendo este um ponto importante parao desenvolvimento de uma proposta de uma plataforma que esteja enquadrada às já desenvolvidas.No entanto, também é importante ter em conta as limitações existentes, pelo fato de a plataformaa desenvolver tem o objetivo de vir a ser base para futuros trabalhos desenvolvidos por alunos doMIEEC.2.1IntroduçãoOs avanços no ramo da Electrónica Automóvel têm vindo a ter uma ênfase cada vez maior naárea da Engenharia Eletrotécnica, pois o seu uso democratizou-se devido ao aumento da capacidade de efetuar complexas operações de controlo em unidades de hardware de tamanho reduzido,tudo isso a preços competitivos.Esses avanços têm como consequência o aumento das v

culos térmicos convencionais em veículos elétricos. O VEC (Veículo Electrico de Competição) corresponde a um desses projetos, trata-se de um veículo elétrico para uso em competições. O veículo baseia-se no chassi do Fiat Uno 45 S, onde está a ser desenvolvido diversas aplicações pelos alunos do MIEEC.

Related Documents:

Anatomia del sistema nervioso Sistemas, estructuras y celulas que componen nuestro sistema nervioso II Organizaci6n general del sistema nervioso I) Cl!luias del sistema nervioso I) Tl!cnicas y orientaciones en neuroanatomla I] Ml!dula espinal I) Las cinco divisiones principales del encl!falo

Il Sistema Nervoso coordina le attività della vita di relazione e svolge le seguenti funzioni: Il Sistema Nervoso riceve stimoli ed elabora risposte; memorizza informazioni; elabora ragionamenti. L’unità fondamentale del sistema nervoso è il neurone una speciale cellula che trasmette gli impulsi nervosi. Il Sistema Nervoso. Il .

4. Menciona unidades en el sistema ingles que utilicen múltiplos y submúltiplos. 5. Expresar las unidades del sistema ingles que utilicen comúnmente prefijos. SISTEMA INTERNACIONAL 2. Seleccionar la unidad adecuada en el sistema internacional para diversas magnitudes fís

El Sistema Operativo Linux Javier Parapar Contenido Contenido 1 El software libre y Linux. Distribuciones 2 Primeros pasos en Linux 3 Instalaci on de distribuciones 4 Gesti on de archivos (I) 5 Gesti on de archivos (y II) 6 Edicion de archivos de texto 7 Gesti on de usuarios y procesos 8 Shell scripts 9 Arranque, reinicio y apagado del sistema 10 Logs del sistema 11 Sistema gr afico Xwindow

sobrepasado por el surgimiento de nuevas razas de patógenos. En contraste, la resistencia horizontal se limita a la tasa de desarrollo de la enfermedad, es decir, la enfermedad se desarrolla pero a niveles bajos, lo que hace que el cultivo sea tolerante. Quizás una de las mayores limitaciones de la resistencia en plantas es

Metodología de desarrollo 141 Capítulo 9 - METODOLOG A DE DESARROLLO La replicación de una aplicación es esencial para hacerla tolerante a fallos, pero esa replicación resulta cara de realizar.

7. Sistema de Gestión de Continuidad del Negocio (SGCN) El Sistema de Gestión de Continuidad del Negocio se basa en la definición de la norma internacional ISO 22301:2012, la cual emite los criterios para establecer y monitorear un sistema cíclico de gestión con las actividades que se deben realizar para salvaguardar los

counseling and consultation for little or no cost to the employee. VA offers up to 15 days a year of military leave support for reservists and National Guard, and supports our nurses’ ability to serve both their country and Veterans. VA employees have the benefit of the Federal Employee Retirement System and Thrift Savings Plan. VA also offers continuation of federal service from .