visão geral
Quer se trate de software de entretenimento veicular, software de assistência ao motorista ou software de direção autônoma, o suporte de software trouxe grandes benefícios e conveniência para a indústria automotiva e usuários. No entanto, assim como as peças mecânicas requerem limpeza, lubrificação e substituição, o software requer manutenção.
Fabricantes de equipamentos originais (OEMs) e fornecedores de nível 1 podem ser muito bons em selecionar peças automotivas que facilitam a manutenção regular, como trocar o óleo do motor ou a corrente de distribuição, mas quando se trata de software automotivo, eles podem não saber por onde começar. À medida que as funções de software se tornam cada vez mais complexas, se a arquitetura de software selecionada agora não for adequada, poderão ser necessárias altas taxas de manutenção de software nos próximos anos. Portanto, os OEMs e fornecedores de Nível 1 devem prestar atenção ao sistema de software e arquitetura de software do veículo e levar em consideração a manutenção regular exigida pelo software, como patches de vulnerabilidade de segurança de software ou atualizações de software.
Este artigo descreve como garantir que os veículos definidos por software sejam equipados com soluções de segurança e proteção de última geração, além de explicar a importância do uso de software de código aberto - não apenas para permitir que os OEMs se concentrem no desenvolvimento de aplicativos de próxima geração e atender às necessidades do consumidor, mas também para controlar os custos.
introdução
Software define a pista em forma de U da indústria automotiva
Nos últimos anos, o campo da eletrificação de veículos e da direção autônoma progrediu rapidamente, e o principal desafio da indústria automotiva mudou de peças mecânicas para sistemas eletrônicos e software de bordo.
Anteriormente, os problemas que surgiam durante a fase de projeto automotivo eram frequentemente relacionados a peças mecânicas. Para garantir um fornecimento adequado de peças mecânicas, os OEMs geralmente firmam contratos de longo prazo com fornecedores de Nível 1 e Nível 2 para manter as peças de reposição disponíveis por pelo menos dez anos após o término da produção de um veículo. Quando um carro precisa de manutenção, o consumidor final no final da cadeia de valor paga fornecedores de nível 1 e nível 2 indiretamente por peças até o final da vida útil do veículo.
À medida que os "carros definidos por software" gradualmente se tornam a principal tendência de desenvolvimento da indústria automotiva, os problemas que precisam ser resolvidos no processo de design do carro estão principalmente relacionados ao software e estão mais relacionados aos consumidores finais. Todo proprietário de carro deseja aproveitar os recursos mais recentes enquanto mantém seu carro seguro, mas poucos proprietários de carros estão dispostos a pagar por atualizações frequentes de recursos de segurança.
As constantes mudanças no mercado forçam a indústria automotiva a acompanhar e acompanhar a tendência de desenvolvimento. Isso pode ser visto na espantosa expansão departamental dos departamentos de engenharia de software de empresas como Renault ou Volkswagen.
“Em 2011, a Renault e a Volkswagen não conseguiam nem mesmo encontrar um engenheiro de software interno.” Hoje, essas duas montadoras conhecidas têm, cada uma, uma grande equipe de engenheiros de software.
Ao mesmo tempo, os fornecedores estão lutando para formar seus próprios departamentos de engenharia de software. Tomemos como exemplo o grupo alemão Continental, que produziu o primeiro pneu sulcado para automóveis do mundo, que só em 2021 vai investir 31 milhões de euros no software de desenvolvimento interno da empresa. A principal unidade de negócios da Continental Automotive Technology (dividida nas unidades de negócios Vehicle Networking Technology (VNI), Autonomous Driving and Safety Technology (AMS)) tem cerca de 89.000 funcionários, enquanto a unidade de negócios de pneus tem agora apenas cerca de 57.000 funcionários. A Continental não é uma exceção: o conhecido fornecedor de sistemas de limpeza e iluminação Valeo Group e o conhecido fornecedor de sistemas de escapamento Marelli tomaram medidas semelhantes para expandir suas vantagens profissionais no campo de soluções eletrônicas e software.
Embora várias empresas tenham estabelecido seus próprios departamentos de software uma após a outra, deve-se admitir que existe uma grande lacuna entre as expectativas do mercado e os custos crescentes à medida que a dificuldade técnica aumenta.
Com base nas considerações acima, o desafio para os OEMs será como implantar sistemas cada vez mais complexos e controlar os custos recorrentes anuais de manutenção dos sistemas.
Estado inicial
Redefinindo a arquitetura automotiva na era dos dados
A partir do estado atual de desenvolvimento da indústria automotiva, fica claro que, no futuro, a quantidade de dados que os carros precisarão processar chegará a dez megabytes por dia. Os sensores de longo e curto alcance (como LiDAR e câmeras) no carro coletarão todos os tipos de dados e o número de sensores aumentará.
Além da condução automática que requer processamento de dados e cálculos, existem sistemas de entretenimento a bordo e sistemas de diagnóstico de falhas do veículo estendido dentro do carro (aumentando ainda mais o diagnóstico de falhas realizado pelo sistema de diagnóstico automático de bordo OBD-II). Todos esses três sistemas veiculares requerem processamento de dados estável.
Então, todos esses dados podem ser enviados para o servidor em nuvem? As chances disso são quase nulas. A realidade é que o sistema do veículo processará alguns dos dados localmente antes de enviar os dados principais ou agregados para a nuvem.
" Para garantir a capacidade de processamento de dados de dezenas de petabytes por dia, um mecanismo de computação deve estar embutido no sistema automotivo."
Como resultado, a quantidade de dados que precisam ser carregados aumenta consideravelmente. Anteriormente, a unidade de controle eletrônico (ECU) de um veículo costumava estar localizada perto dos sensores e atuadores aos quais estava conectada e, portanto, espalhada pelo interior do carro. Hoje, os fabricantes de equipamentos originais (OEMs) estão se voltando para a "Arquitetura Elétrica e Eletrônica Automotiva" (EEA), que permite a consolidação e integração de unidades de controle eletrônico e usa Ethernet para interconectar as várias unidades de controle eletrônico. Essa nova arquitetura também incluirá de 1 a 5 computadores de alto desempenho (HPCs) integrados.
Abaixo, descrevemos as muitas implicações da mudança da arquitetura legada para a nova arquitetura EEA, principalmente em termos de manutenção de hardware e software.
Fonte: Aliança Renault-Nissan
Complexidade crescente
complexidade de hardware
No setor automotivo, o design do hardware eletrônico não é baseado em uma unidade central de processamento (CPU) e placas de expansão PCIe instaladas em uma placa-mãe como um computador, mas em um "sistema em um chip" (SoC). Um system-on-chip é um circuito integrado que inclui todos ou a maioria dos componentes de computação. Na verdade, o sistema no chip de um carro geralmente inclui várias CPUs para desempenho de computação e segurança na direção. Essas CPUs incluem unidades de processamento de sinal digital (DSP), unidades de processamento gráfico (GPUs), aceleradores de vídeo, unidades de processamento de imagem (IPUs) e interfaces de barramento CAN. Em outras palavras, um SoC é um sistema muito complexo.
Fonte: Texas Instruments TDA System-on-Chip
"O hardware já é tão complexo que as montadoras precisam de mais proezas de software para superar os desafios futuros, porque o software é mais complexo do que o hardware."
Olhando para o desenvolvimento do hardware automotivo, não é difícil descobrir que a complexidade dos SoCs ainda está aumentando e ainda não atingiu o pico de desenvolvimento. Na verdade, mesmo que o desempenho do hardware do veículo ainda não esteja na faixa do Teraflop, já existem alguns chipsets no mercado que contêm 16 núcleos de CPU. É previsível que os carros em breve introduzam CPUs de 80 núcleos ou mesmo CPUs multi-core com melhor desempenho de computação.
Complexidade de Software e Microsserviços
A indústria automotiva está gradualmente mudando de "carros definidos mecanicamente" para "carros definidos por software". Impulsionado por esta tendência, o ciclo de desenvolvimento do veículo foi reformulado, e os métodos de trabalho e as habilidades necessárias para o desenvolvimento do veículo também deram início a um ponto de virada abrangente. Essas mudanças criaram desafios adicionais para o setor. Para enfrentar os desafios, as montadoras ampliaram suas equipes profissionais e não pouparam gastos na contratação e treinamento de profissionais. Por enquanto, o custo do talento ainda está em alta. Ao recrutar talentos profissionais em larga escala, as empresas enfrentam outro desafio: como atrair talentos capazes que possam estabelecer uma base sólida de estratégia de software para a empresa. Outra abordagem é treinar o pessoal atual dos OEMs e seus fornecedores, ensinando-lhes as novas habilidades necessárias para enfrentar a onda de mudança. No entanto, aprender habilidades é muito simples, mas remodelar a maneira de pensar inerente dos funcionários é muito difícil, especialmente quando o desenvolvimento desse campo é altamente maduro.
Ao mesmo tempo, as demandas dos consumidores finais por funções cada vez mais complexas estão aumentando gradualmente. De acordo com dados publicados pela McKinsey, “na última década, a complexidade média de um único projeto de software na indústria automotiva cresceu 300%”. Os aviões F-35 ou Boeing 787 Dreamliners têm muito mais. Estima-se que, até 2025, o número de linhas de código em execução nos carros chegue a 200 milhões e, para sistemas de direção autônoma L5 (totalmente autônomos), o número de linhas de código pode chegar a 1 bilhão.
A seguir estão os níveis de automação de direção definidos pela Society of Automotive Engineers (SAE)
Classificação da Sociedade de Engenheiros Automotivos (SAE) dos Níveis de Automação de Direção
Além disso, os algoritmos de inteligência artificial (IA) ou aprendizado de máquina (ML) também aumentam em grande medida a complexidade do software integrado.
Fonte: McKinsey
ameaça de segurança cibernética
Segundo relatos, em 1983, Kevin Poulsen, o primeiro "hacker" no campo do software e da Internet, invadiu o predecessor da Internet, a Arpanet. Naquela época, os ladrões de carros precisavam quebrar as janelas e conectar os fios sob o volante para roubar o carro com sucesso. Hoje, com a proliferação de software veicular, a indústria automobilística está ainda mais vulnerável ao cibercrime.
Em 1983, a empresa alemã BOSCH inventou o barramento CAN, que nasceu antes da World Wide Web e da Internet. Como o barramento CAN é inerentemente incapaz de resistir a ataques de hackers, quando está embutido em um carro moderno, o barramento CAN oferece uma oportunidade aos hackers. Assim como o incidente de hacking de Kevin Paulson expôs as brechas da Internet, o "hacker que sequestrou remotamente um incidente de jipe" expôs muitos riscos de segurança dos sistemas de navegação automotiva.
Um relatório sobre segurança automotiva global divulgado em 2021 afirmou que “já existem 110 vulnerabilidades e exposições de segurança comuns (CVEs) na indústria automotiva, com 33 somente em 2020, em comparação com 24 em 2019”. incluídos no CVE. O relatório acima mencionado também apontou que, em agosto de 2020, foram encontradas mais de 300 vulnerabilidades em softwares de 40 ECU desenvolvidos por 10 empresas diferentes. As autoridades estão estudando cuidadosamente o impacto econômico das violações de segurança e introduziram regulamentações para evitar ameaças à segurança.
O padrão ISO/SAE 21434 "especifica os requisitos de engenharia para gerenciamento de riscos de segurança cibernética em todos os estágios de conceito, desenvolvimento de produto, produção, operação, manutenção e descomissionamento de sistemas elétricos e eletrônicos (E/E) de veículos rodoviários (incluindo seus componentes e interfaces) ". Além disso, as Nações Unidas adotaram o Regulamento nº 155, "Regulamentos unificados relativos à aprovação de segurança cibernética e sistemas de gerenciamento de segurança cibernética para veículos". O regulamento descreve "regulamentos unificados sobre a aprovação de segurança cibernética de veículos e sistemas de gerenciamento de segurança cibernética".
Como resultado do Regulamento 155 da ONU, os OEMs e seus fornecedores devem colaborar no desenvolvimento de patches ou correções de segurança de software para prevenir e limitar o cibercrime durante o uso do veículo. Toda entrega de software, seja seu objetivo introduzir melhorias, corrigir bugs ou resolver problemas de segurança, precisa passar por uma avaliação de segurança cibernética e um processo formal de aprovação antes de ser enviado para o veículo.
Para atender a esse mandato e às expectativas do cliente, os OEMs e fornecedores de nível 1 devem entender as complexidades do software veicular. No mundo do software, é muito raro existir apenas um método para implementar uma função ou serviço. Os arquitetos de software devem tomar decisões informadas, porque reduzir a complexidade do gerenciamento de software é a única maneira de reduzir os custos de manutenção de software a longo prazo.
"O desafio não é apenas entregar um sistema de software, mas como mantê-lo a longo prazo. As montadoras estão totalmente preparadas para isso?"
Mas os riscos de segurança cibernética não se limitam ao software e, às vezes, o hardware também pode expor vulnerabilidades de segurança - as vulnerabilidades de segurança "Meltdown" e "Spectre" encontradas em muitos produtos são uma forte prova. Claramente, essas vulnerabilidades de segurança aumentam a complexidade do projeto do sistema, pois os arquitetos de software precisam antecipar possíveis vulnerabilidades de hardware enquanto consideram os riscos de software.
considerações de segurança
A complexidade do sistema não é o único desafio enfrentado pela indústria automotiva. Acabamos de falar sobre cibersegurança. Na verdade, a segurança cibernética do veículo e a garantia de segurança são dois tópicos separados, porque a segurança dos sistemas de bordo não garante a segurança dos passageiros. Um carro é um dispositivo móvel que geralmente pesa mais de uma tonelada: o carro não precisa apenas proteger a segurança de seus ocupantes, mas também do ambiente em que é conduzido.
Se os passageiros não usarem cinto de segurança, mesmo o carro com o fator de segurança mais alto não pode garantir totalmente a segurança dos passageiros. Embora os dois conceitos sejam bastante diferentes, sua relação é inseparável.
O acima mencionado "hacker sequestrando um incidente de jipe remotamente" prova este ponto.Depois que os hackers destroem a segurança da rede do carro, isso também representa uma ameaça à segurança pessoal dos passageiros. Isso é especialmente importante de se considerar, pois cada vez mais sistemas de segurança ativos são instalados nos carros para evitar acidentes. Como os sistemas de segurança ativos dependem de software para funcionar corretamente, eles são vulneráveis a ataques de segurança cibernética. Para isso, a indústria automotiva introduziu o conceito de Segurança Funcional (FuSa), que visa fornecer uma estrutura para OEMs e seus fornecedores, permitindo que o conceito de segurança permeie vários processos e se torne o núcleo de conceitos, produção, entrega, manutenção e outros processos. centro de gravidade.
ISO 26262 "Functional Safety of Road Vehicles" é um padrão de segurança internacional que restringe e especifica a segurança funcional de sistemas elétricos e/ou eletrônicos instalados em veículos rodoviários produzidos em massa. A norma ISO 26262 define a "segurança funcional (FuSa)" automotiva como "a ausência de riscos não razoáveis devido à falha de sistemas elétricos e eletrônicos ".
A segurança funcional não é um problema puro do sistema de hardware, nem um problema puro do sistema de software, é um problema sistêmico, envolvendo a operação e o processo específicos do sistema de hardware e do sistema de software.
segurança de hardware
Quanto ao sistema de hardware, ele só pode ser instalado no carro após o system-on-chip (SoC) e a unidade de controle eletrônico (ECU) que atendem a rígidos requisitos de segurança. A norma ISO 26262 define o Nível de Integridade de Segurança Automotiva (ASIL), e classifica os requisitos e processos aplicáveis a cada nível de acordo com a importância do sistema em desenvolvimento.
Por exemplo, para atingir o nível ASIL-B, a taxa de cobertura de falha de ponto único do sistema automotivo precisa atingir mais de 90% , enquanto o nível ASIL-D exige que a taxa de cobertura de falha de ponto único atinja mais de 99%. Ao mesmo tempo, o padrão ISO 26262 também dá a definição de "falha de ponto único" e estipula o método de cálculo da "taxa de falha prevista". A norma também define os principais termos necessários e fornece métodos de avaliação correspondentes para ajudar os leitores a entender completamente o sistema de segurança dos automóveis.
Prevendo taxas de falha de hardware
O padrão ISO 26262 descreve várias técnicas para avaliar a taxa de falha de componentes semicondutores, que podem avaliar a incidência de estresse elétrico, falha de transistor ou falha de pacote. Esses tipos de falha e suas respectivas taxas de ocorrência dependem principalmente do tipo de circuito, tecnologia de implementação e fatores ambientais como umidade, temperatura, pressão, interferência eletromagnética, etc.
O padrão ISO 26262 também distingue entre as taxas de falha esperadas e a confiabilidade esperada dos componentes. Além disso, a norma estabelece que, em casos especiais, um único ponto de falha pode causar um risco à segurança de vários componentes individuais. A norma esclarece ainda que esses cenários de risco podem ser tratados por meio de uma análise de falha relevante (DFA) e identificação de pontos de iniciação de falha relevantes (DFI).
Detecção de falha de transmissão de dados
Para atender aos requisitos de segurança acima, as empresas de semicondutores propuseram um grande número de mecanismos e soluções de detecção de hardware. Os mais comuns incluem:
• Código de paridade: Adicionando um "bit de paridade" no fluxo de comunicação no chip para atingir o objetivo de detectar a transmissão de dados. O bit de paridade é o código de detecção de erro mais simples e o método de detecção é direto: se o bit de paridade for definido como 0, o número de códigos de transmissão é par; se o bit de paridade for definido como 1, o número de códigos de transmissão é ímpar individual. Se a extremidade receptora receber um número par de códigos e souber a posição do bit de paridade, poderá removê-lo e encontrar o número transmitido. Dessa forma, se o receptor obtiver um número ímpar de codificações, isso significa que houve corrupção de dados durante a transmissão. Embora os códigos de paridade possam detectar erros de transmissão, eles não podem recuperar as informações corretas, portanto, as informações precisam ser reenviadas.
• A verificação de redundância cíclica (CRC) é outra ferramenta usada para detectar falhas na transmissão de dados. A verificação de redundância cíclica usa o princípio de divisão e resto para detectar erros. Anexa um restante de um tamanho especificado aos dados e, em seguida, verifica na extremidade receptora se os dados foram alterados. Após receber a mensagem, a ponta receptora faz uma divisão polinomial na parte que contém o CRC: o CRC recebido com a mensagem deve ser consistente com o CRC calculado sobre a mensagem recebida, caso contrário significa que há um erro de transmissão.
• Os códigos de correção de erros (ECC) são uma solução aprimorada para verificação de paridade porque incluem uma maneira de recuperar as informações originais mesmo se o hardware estiver danificado . Existem muitos tipos de códigos de correção de erros e até mesmo os padrões 5G sem fio incluem novos mecanismos de código de correção de erros.
Embora o objetivo seja detectar problemas de transmissão e recuperar as informações originais transmitidas, essas técnicas de inspeção requerem codificação adicional para serem transmitidas com as informações. Isso tem um impacto direto na largura de banda real da rede, que diminui com o tempo: se 1 bit de cada byte for usado para detecção de erro e 7 bits para dados reais, a largura de banda será reduzida em 1/8 ou 12,5%.
No entanto, às vezes ocorrem interrupções de transmissão. As transferências interrompidas podem ocorrer devido a interrupções de comunicação física ou, mais frequentemente, porque um processo ficou parado por muito tempo. Portanto, usamos "tempo limite de comunicação" para detectar a quantidade de perda de comunicação.
Detectar erros de tempo de execução
Conforme mencionado anteriormente, o padrão ISO 26262 cobre problemas que podem ocorrer no nível do transistor. Atualmente, as empresas de semicondutores costumam usar ferramentas de inspeção de hardware para verificar a operação correta. Mas as empresas de semicondutores também usam controladores de segurança para coletar informações de falhas em todo o sistema, analisá-las e passar as informações de falhas para a arquitetura de alto nível do sistema de software.
Outra abordagem de baixo custo para aumentar a conformidade de segurança que surgiu recentemente é o "autoteste integrado" (BIST). Este método nasceu porque os fabricantes de semicondutores precisavam de uma maneira de identificar defeitos de fabricação em produtos e melhorar o processo de inspeção de qualidade. Aproveitando ao máximo essas funções de teste aprimoradas no sistema e usando-as enquanto o processador está funcionando normalmente, é possível identificar com eficiência as falhas de tempo de execução.
Mecanismo de Detecção de Redundância
Para atender aos requisitos de segurança, os fabricantes geralmente adotam o método de duplicação do sistema. Sob os mesmos requisitos de segurança, se os dois sistemas forem implementados separadamente, a segurança aumentará.
Redundância modular dupla (DMR) e redundância modular tripla (TMR) referem-se a duplicar ou triplicar um sistema ou um elemento em um sistema e fornecer o mesmo sinal de entrada para esses sistemas ou módulos e comparar o método geral de sinais de saída.
O princípio da redundância de módulo triplo é o voto da maioria , e o resultado de saída da maioria é a saída final: se dois dos três sistemas tiverem o mesmo resultado de saída, esse resultado é o resultado de saída correto. No caso de módulos duplos, se os resultados de saída forem inconsistentes, há um erro no sistema.
A redundância modular dupla (DMR) e a redundância modular tripla (TMR) são usadas em diferentes níveis de hardware, incluindo nível de módulo, nível de chip e, em alguns casos, até nível de sistema.
Alguns SoCs suportam a funcionalidade lockstep dual-core . O mecanismo de hardware seguro é implementado por meio de redundância de módulo duplo (DMR), fornecendo software idêntico para dois núcleos de CPU idênticos e compartilhando o mesmo ciclo de clock. A cada ciclo de clock, haverá um comparador lógico para verificar se os resultados de saída dos dois núcleos são consistentes e, caso sejam inconsistentes, um erro será reportado.
No entanto, as CPUs de alto desempenho geralmente têm uma estrutura mais complexa e um determinismo mais fraco , portanto, o efeito real do método lockstep dual-core pode não ser satisfatório. Como resultado, surgiram algumas alternativas mais complexas ao lockstep dual-core, como o uso de "ilhas de segurança" para realizar tarefas de inspeção em núcleos de CPU que mantêm alta integridade de segurança. Além disso, outro método de otimização do método lockstep dual-core é "CPU core-lockstep" .
Assim como as técnicas de detecção de falhas mencionadas reduzem a largura de banda real da comunicação, as técnicas de redundância da CPU também consomem seu próprio poder de processamento disponível. O método lockstep dual-core ou seu método de extensão reduzirá o poder de computação efetivo do sistema no chip em 50% (a redução no poder de computação é um pouco menor ao usar o método Split-Lock). Além disso, esta tecnologia também leva a maiores custos de desenvolvimento e custos de hardware porque a redundância deve ser adicionada.
segurança de software
As empresas de semicondutores geralmente exigem o uso de software especializado para garantir a conformidade com a segurança do hardware. Em outras palavras, alguns sistemas baseados em nuvem exigem que o software implemente recursos específicos para realizar todo o seu potencial de segurança, como o "autoteste integrado (BIST)" mencionado no capítulo sobre segurança de hardware.
A plataforma de processamento automotivo S32 lançada pela NXP Semiconductors é uma das séries SoC automotivas mais populares.
A empresa acredita: "A arquitetura do software de segurança S32 está envolvida no trabalho durante a inicialização, operação e recuperação de falhas."
Fonte: Arquitetura de software seguro NXP S32
Nem todo software é compatível com a segurança e nem todo software atende aos requisitos de segurança. Além disso, as taxas de certificação de software também são caras. Portanto, com a integração gradual de unidades de controle eletrônico, tornou-se gradualmente uma tendência da indústria incluir diferentes níveis críticos de segurança no mesmo SoC ou unidade de controle eletrônico. Essa tendência pode otimizar o controle de custos e o desempenho. Unidades de controle eletrônico para sistemas de infoentretenimento em veículos são um exemplo interessante.
Agora é prática comum na indústria combinar o console central, painel de instrumentos, head-up display e funções de monitoramento de passageiros na mesma unidade de controle eletrônico. Quando combinados, alguns elementos de exibição e elementos de som têm requisitos de segurança mais altos do que outros. A figura abaixo apresenta o software principal que permite a integração da ECU.
A principal diferença entre as diferentes opções é onde os recursos de conformidade de segurança são tratados.
• Na opção a, a separação de hardware é gerenciada por um hypervisor compatível com ASIL/segurança.
• Na opção b, a separação de hardware é obtida usando 2 tipos de núcleos no SoC. Por exemplo, use um ou alguns núcleos ARM Cortex-M para comunicação de veículos e necessidades de segurança e outro conjunto de núcleos de uso geral para funções de computação de ponta.
• Na opção c, a separação de hardware não é feita no SoC, mas no nível do hardware - usando dois SoCs dedicados diferentes (um para segurança e outro para uso geral) para obter a separação de hardware.
Tal arquitetura não só aumenta a dificuldade de desenvolvimento de software, mas também apresenta integração complexa e desafios de depuração.
Métodos semelhantes ou outros métodos novos podem ser usados, como a introdução da plataforma adaptativa AUTOSAR no sistema. Essas são opções de otimização que geralmente são baseadas no SoC específico, e recursos específicos geralmente vêm com complexidade adicional.
A complexidade do hardware continuará a crescer para expandir o poder de computação dos SoCs. Além disso, os requisitos de segurança aumentam a complexidade do sistema. Integrar o poder de computação e a segurança em um único sistema no chip se tornará cada vez mais complexo. As empresas de semicondutores terão que aumentar o custo dos SoCs para atender aos requisitos de segurança correspondentes.
Da mesma forma, quanto mais complexo o sistema, mais difícil e caro é autenticar. A curva de crescimento dos preços tem menos probabilidade de ser linear e mais provável de ser exponencial.
Mas garantir a conformidade com a segurança requer investimentos adicionais em software. O padrão ISO 26262 exige que o processo de desenvolvimento do sistema siga um modelo de ciclo de vida em forma de V. Isso significa que os desenvolvedores de software primeiro capturam as necessidades do cliente e depois definem a funcionalidade com base nessas necessidades. Os desenvolvedores de software precisam decompor as funções em sistemas de hardware e sistemas de software; os sistemas de software são subdivididos em funções. Além disso, é necessário definir, criar ou reativar um processo de teste específico e, em seguida, realizar testes no nível funcional, no nível do software, no nível do hardware e no nível do sistema sucessivamente. Essa abordagem de desenvolvimento de sistemas vem com um conjunto de processos para executar o software, incluindo revisão de código, detecção de desvios de requisitos, execução de testes, medição da cobertura de teste e muito mais.
"As montadoras devem estar preparadas para incorrer em altos custos de manutenção de software."
Agora, assumimos que as 100 milhões de linhas de código existentes incorporadas no carro atual são todas compatíveis com a segurança (pode não ser o caso), de acordo com o modelo de ciclo de vida em forma de V definido pelo padrão ISO 26262, quanto tempo precisamos escrever 100 milhões de novas linhas de código para elevar o total a 200 milhões de linhas de código até 2025? Quantos engenheiros de software precisamos para trabalhar juntos?
Com 100 milhões de linhas de código agora instaladas, os OEMs e fornecedores de nível 1 devem ser capazes de estimar aproximadamente o custo de adicionar 100 milhões de linhas de código no COCOMO ou qualquer outro método. Mas este é apenas um custo estimado, qualquer alteração resultará em uma mudança no custo.
Portanto, para um carro com um sistema de direção autônoma de nível 5, como é a carga de trabalho estimada de 1 bilhão de linhas de código? Da mesma forma, quanto tempo levaria para escrever especificações, implementar e testar um software dessa magnitude se a maior parte do conteúdo não pudesse ser reutilizada?
Usar código aberto é a única maneira sustentável, detalhada na seção "Recomendações".
Isolar interferência
Como mencionado anteriormente, a integração de ECU de hardware é uma tendência importante. Na maioria dos casos, isso significa combinar componentes críticos de segurança e componentes de processamento comuns na mesma unidade de controle eletrônico. Mas o sistema de segurança deve ter a função "livre de distrações". Em outras palavras, se um sistema combina componentes críticos e não críticos para a segurança (por exemplo, dentro da mesma ECU), deve ser demonstrado que o ambiente não crítico para a segurança não pode interferir nas partes seguras do sistema, causando problemas de segurança. problemas.
Por exemplo, assegure-se de que o planejador não seja corrompido, que um processo não possa encerrar o sistema e que o heap de memória seja resiliente a estouros de buffer.
Depois de revisar os incidentes CVE, descobrimos que a maioria dos incidentes CVE são baseados em backdoors, estouros de memória ou comportamento acidental/não intencional de componentes de software (ou hardware): portanto, o foco dos CVEs é destacar as ameaças à segurança. Descobrimos novas vulnerabilidades CVE todos os dias. Mesmo que seja projetado de acordo com a norma ISO 26262 (padrão "Road Vehicle Functional Safety") e siga rigorosamente o processo Automotive Spice (Software Process Improvement and Capability Measurement Standard), um sistema operacional em tempo real (RTOS) com nível ASIL D terá segurança vulnerabilidades.
Mas de qualquer forma, nenhuma proteção significa falta de segurança, isso é um fato com o qual todos concordam.
O padrão ISO 26262 não é suficiente para garantir a segurança dos carros. De acordo com os requisitos técnicos avançados existentes, devemos incorporar a segurança das funções esperadas (SOTIF) na análise do sistema de acordo com a norma ISO/PAS 21448 (norma "Segurança das funções esperadas dos veículos rodoviários"). Este é outro problema difícil que precisa ser resolvido com urgência.
"Quanto mais complexo é um sistema, mais difícil é avaliar e demonstrar sua conformidade com a segurança."
sugestão
Encontre maneiras eficazes de resolver problemas difíceis e questões de segurança
Nesta fase, podemos resolver os seguintes problemas:
• Processe mais dados do veículo, mais rápido
• Desafios da crescente complexidade do hardware
• Problema de dispersão de software
• Desafios adicionais impostos por ameaças cibernéticas
• Necessidades de manutenção de longo prazo do software
• Requisitos de segurança separados ou comuns para hardware e software
Em seguida, exploraremos casos de melhores práticas em aviônicos, desenvolvimento de software de código aberto e outras indústrias para lidar com esses desafios.
limitar a poluição segura
Provamos que o uso de código aberto é a única maneira sustentável de crescer. Mas isso não significa que devemos esperar modificar o software de código aberto para atender às necessidades de nossos carros. Por exemplo, a poluição da segurança ocorre quando mais e mais partes do sistema começam a exigir proteção de segurança. Se nos concentrarmos em reduzir o tempo de lançamento no mercado em vez de melhorar a segurança do usuário final, acabamos ignorando a pesquisa de arquitetura correspondente. A poluição da segurança limita muito a usabilidade do software de código aberto,
Porque a grande maioria do software de código aberto não atende e não pode atender aos requisitos de segurança. Para OEMs, impor altos requisitos de conformidade de segurança em várias partes do sistema, como exigir que cada componente seja ASIL D, parece ser mais fácil do que atualizar um sistema ASIL B para ASIL D. No entanto, isso resulta em maior complexidade e custo, além de reduzir a funcionalidade. Por exemplo, um sistema operacional compatível com segurança oferece suporte a menos recursos do que um sistema operacional de uso mais geral. Além disso, toda vez que uma alteração é feita (como um patch CVE), é necessária uma avaliação de segurança, portanto, adotar medidas de segurança e conformidade com a proteção ao mesmo tempo levará a outra escalada de complexidade.
Portanto, uma vez que tal sistema é implantado em um veículo, os custos operacionais podem aumentar rapidamente. E uma vez configurada, a arquitetura do sistema pode ser difícil de mudar. Para os OEMs, a única maneira de evitar explosões de custos é controlar racionalmente as margens de segurança do sistema.
Recentemente, com a integração da direção autônoma e das unidades de controle eletrônico, os requisitos de segurança afetaram muitos componentes do veículo, como os sistemas de infotainment veiculares.
As empresas automobilísticas podem aprender com a experiência de outras indústrias quando se trata de evitar a poluição da segurança. Por exemplo, a arquitetura do sistema aviônico define claramente a distinção entre segurança do sistema e componentes não relacionados à segurança. Por exemplo, o sistema de infoentretenimento a bordo não interfere nos componentes de segurança da aeronave. Alguns componentes de segurança também podem controlar componentes não relacionados à segurança, como o anúncio do capitão, que pode controlar o sistema de infoentretenimento a bordo.
Nossa proposta para futuras arquiteturas elétricas e eletrônicas é considerar o suporte a dois tipos de canais de comunicação (no nível de hardware da ECU): canais seguros e canais gerais. Componentes genéricos no sistema podem interagir com componentes compatíveis com segurança (acessar sensores ou atuadores e ler o status deles) e, quando disponíveis, responder usando sistemas de mensagens do tipo nativo da nuvem (componentes seguros): segurança em primeiro lugar. Componentes genéricos devem ser proibidos de definir parâmetros ou controlar componentes seguros.
Não é recomendado reconstruir os componentes de segurança e não segurança da ECU. Propõe-se que dois tipos diferentes de System-on-Chip (SoC)/Central Processing Unit (CPU) sejam responsáveis pela segurança e recursos comuns na mesma ECU (conforme mostrado na opção c acima mencionada) separação de hardware). Dessa forma, não é necessário conectar todos os SoCs/CPUs de computação de alto desempenho ou computação de ponta a canais de comunicação seguros, reduzindo assim a complexidade do design de hardware e software.
A McKinsey espera que o hardware e o software sejam adquiridos separadamente, tornando "a aquisição mais competitiva, o dimensionamento mais fácil e permitindo plataformas padronizadas para software de aplicativo, mantendo a concorrência no lado do hardware".
Por esse motivo, as próximas etapas para OEMs e fornecedores de nível 1 são adquirir segurança de hardware e software e componentes de uso geral, respectivamente.
Os requisitos de segurança de hardware criam barreiras à entrada que impedem a concorrência em larga escala. Remover o requisito de segurança para alguns módulos de hardware (como HPC) na arquitetura do sistema levará a uma repetição da competição e reduzirá os custos da lista de materiais (BOM).
Por exemplo, as empresas de semicondutores podem aproveitar esta oportunidade para oferecer CPUs com qualificação AEC-Q100 para a indústria automotiva sem certificação ASIL. Podemos esperar CPUs mais poderosas com vários núcleos sem um grande aumento de preço em comparação com PCs/servidores.
Hoje, quantos protótipos criados no sistema operacional Linux precisam ser redesenhados, portados e adaptados para finalmente rodar em um "sistema operacional seguro em tempo real"? Imagine se fosse desenvolvida uma prova de conceito (POC) que pudesse ser executada imediatamente no hardware de destino, distinguir os componentes compatíveis com segurança dos genéricos reduziria muito a necessidade de soluções de virtualização compatíveis com segurança e aumentaria o uso de sistemas operacionais personalizados ( baseados em Linux ou não) que atendem aos padrões de segurança. Nesse ponto, os OEMs poderão usar o sistema operacional Linux e o software de código aberto. Assim como no uso de um sistema operacional seguro, a obtenção de requisitos de segurança em um domínio limitado também melhorará o uso de recursos: reduzindo o número necessário de engenheiros especializados em segurança. Haverá menos pressão para recrutar.
Adote código aberto e sistema operacional Linux
O Facebook/Meta, Airbnb, Netflix (e muitos outros) tiveram sucesso porque tentaram substituir o Windows ou Linux da Microsoft por seu próprio sistema operacional ou porque usaram código aberto e focaram no atendimento ao cliente? Eles certamente estão muito familiarizados com sua pilha de software, mas não desperdiçam energia reinventando o que já existe na comunidade de código aberto. Se eles encontrarem um bug ou desenvolverem uma versão aprimorada de um módulo de código aberto, eles o liberam para a comunidade, tornando assim a funcionalidade do módulo upstream, beneficiando mais pessoas e envolvendo toda a comunidade no processo de manutenção. É assim que o código aberto melhora e evolui.
Recomendamos que os OEMs e fornecedores de Nível 1 trabalhem com fornecedores Linux comerciais para suporte de longo prazo e manutenção de segurança do kernel do Linux e pacotes estendidos de software de código aberto. Isso permite que eles se concentrem em suas soluções de software e promovam a diferenciação por meio do desenvolvimento de aplicativos e serviços para o cliente.
Ao mesmo tempo, como os veículos estão conectados à nuvem, os OEMs devem considerar trabalhar com distribuidores Linux para fornecer suporte para servidores em nuvem, desktops de engenharia e software Linux veicular. Isso permite que os OEMs recebam níveis mais altos de suporte a um custo menor, reduzindo a carga de gerenciamento de vários fornecedores, vários contratos e vários ambientes de desenvolvimento.
Desenvolva aplicativos automotivos de última geração
A expansão das bases de código de software não é exclusiva da indústria automotiva. Para manter um equilíbrio entre a complexidade do software e a funcionalidade cada vez mais diversificada, o setor de TI como um todo está se afastando de abordagens estáticas e monolíticas para adotar microsserviços e design de software de alta disponibilidade.
caso de microsserviço
A arquitetura de aplicativos baseada em microsserviços permite o desenvolvimento de um único aplicativo como um conjunto de serviços pequenos, estritamente definidos e implementáveis de forma independente. Cada microsserviço é executado em seu próprio processo separado e se comunica com um mecanismo leve, geralmente uma interface de programação de aplicativo HTTP. Esses serviços se concentrarão em funções de negócios específicas e serão implantados de forma independente usando mecanismos totalmente automatizados.
Como analogia, podemos usar uma casa antiga para entender a transição para microsserviços. A transição é como derrubar a parede entre a cozinha e a sala nesta casa, retirar os armários artesanais e substituí-los por sistemas modulares de grandes marcas, e acrescentar utensílios de cozinha e televisores que se comunicam pela LAN doméstica e pela Internet. No exterior da casa nada mudou, e no interior mantém-se a cozinha e a sala, mas estas estão mais modernas, mais confortáveis e com um leque de novidades.
Nesse processo de refatoração de um aplicativo legado, partes do código legado são mantidas por outros (ou seja, a comunidade) e, portanto, geralmente são substituídas por código-fonte aberto, o que significa que quem usa o código não precisa arcar com todos os custos de manutenção . Além disso, o código-fonte aberto tem maior uso do usuário e cobre mais casos do que o código legado que ele substitui: em outras palavras, também é mais confiável.
A transição para o modelo de arquitetura de microsserviços deve visar a substituição de 70% (ou mais) do software legado por software de código aberto equivalente. Desta forma, os esforços podem ser concentrados nos restantes 30% (ou menos) do software que fará a diferença e assim criar valor acrescentado para a empresa.
Como lidar com pontos únicos de falha
O software de alta disponibilidade é projetado para identificar pontos únicos de falha (SPOF). O SPOF faz parte do sistema, se parar de funcionar, fará com que todo o sistema pare de funcionar. Por exemplo, um avião monomotor não pode decolar se seu motor falhar, enquanto um avião comercial bimotor pode decolar se um de seus motores falhar durante a decolagem. Usar um aplicativo com design de microsserviço facilita a identificação de SPOFs e a tentativa de eliminá-los. Existem várias maneiras de eliminar o SPOF: espelhamento, balanceamento de carga, replicação, autocorreção e muito mais. Não é objetivo deste artigo entrar em detalhes, mas o ponto é que a indústria de TI usa projetos de alta disponibilidade para garantir tolerância a falhas e 99,9% de uptime dos servidores. Além disso, ele pode executar manutenção, atualizações e experimentos do servidor imediatamente sem desligar. O veículo não deveria ser tolerante a falhas e funcionar e ter alto tempo de atividade na maior parte do tempo? Não deveríamos ser capazes de atualizar sem estacionar? Quando os trabalhadores da indústria de TI definem essas metas, eles estão cheios de espírito de luta. Mas a realização desses objetivos é muito benéfica e deve ser aplicada à indústria automotiva.
Acontece que a internet é estável e funciona 24 horas por dia, 7 dias por semana. Software altamente disponível e arquiteturas de aplicativos baseados em microsserviços são os principais pilares para que isso aconteça. O software executado no data center é amplamente independente de hardware. Pode ser facilmente implantado em muitos lugares do mundo e também pode ser hospedado por nuvens públicas, como Amazon Web Services, Google Cloud Platform, Microsoft Azure, etc., ou mesmo hospedado no local, sem reescrever aplicativos/serviços ao alternar hosts. Este é apenas um dos seus pontos fortes.
Aplicações de microsserviços são softwares conteinerizados: ou seja, rodam dentro de uma “caixa” (um container) que contém o que precisam para executar. O software conteinerizado tem várias vantagens:
• Se um microsserviço falhar, apenas a parte do ambiente ou contêiner em que ele está sendo executado é afetado e não derruba todo o sistema.
• Para dar suporte à execução de microsserviços, um hardware virtual e um ambiente de sistema operacional são configurados no contêiner.
Isso cria uma abstração de hardware que torna os microsserviços independentes do hardware físico real.
Sites, jogos da web ou aplicativos da web são independentes de hardware: eles podem ser executados em muitos dispositivos com características de hardware, como tamanho da tela, orientação, processador gráfico, webcam.
Acreditamos que em software de missão crítica embarcado, o pacote Snap pode atingir a abstração de hardware necessária (tornando o aplicativo independente de hardware), ao mesmo tempo em que melhora a estabilidade geral do sistema (a falha de uma única função no aplicativo não prejudicará todo o sistema . ).
Um Snap é uma integração agrupada de um aplicativo e todas as suas dependências que serão executadas sem modificação em todas as principais distribuições do Linux e até mesmo em distribuições personalizadas que integram o suporte ao Snap. Milhares de Snaps em 41 distribuições Linux já são usados por milhões de pessoas. Ele contém tutoriais, materiais de suporte, ferramentas para criar e implantar novos aplicativos ou patches. Os OEMs e fornecedores de nível 1 também provavelmente criarão Snaps e os implantarão em ECUs novas e antigas executando Linux. Todos podem usar esses Snaps em seus computadores Linux (e dispositivos IoT) gratuitamente, sem pagar ou desbloqueá-los.
Uma das grandes vantagens do Snap está nas operações e no gerenciamento de aplicativos. Na verdade, eles não apenas garantem segurança imediata, mas também aproveitam ao máximo a portabilidade do hardware sem comprometer a integridade e a confiabilidade do sistema. O Snap pode ser facilmente implantado por qualquer OEM e não precisa ser portado em nenhum dispositivo para ser executado.
Ubuntu Core, uma versão conteinerizada totalmente baseada em snap. O Ubuntu Core é seguro por design: o isolamento de segurança é fornecido por meio do AppArmor e do Secure Computing Mode. Ele também oferece suporte a TPM, inicialização segura e criptografia de disco total.
Com a abordagem holística do Snap para segurança, os sistemas integrados oferecem os benefícios de segurança, imutabilidade, modularidade e capacidade de composição. O software pode ser atualizado pelo ar via delta, que reverte automaticamente se algo der errado (do sistema operacional Linux a qualquer aplicativo único).
A transição da indústria automotiva do barramento CAN para Ethernet levou mais de 30 anos (e apenas parcialmente). Construir sistemas resistentes a falhas é uma obrigação na indústria automotiva e há muitas maneiras de conseguir isso. Além disso, a manutenção da segurança cibernética do sistema precisa ser projetada para ser econômica. Com a implementação dos regulamentos de segurança cibernética ISO/SAE 21434 ("Road Vehicle Cybersecurity Engineering"), agora é um momento apropriado para reconsiderar a arquitetura de hardware e software automotivo sob as três perspectivas de segurança, medidas de proteção e escalabilidade.
Centrado no cliente
Os sistemas de infoentretenimento do carro estão desatualizados há mais de 4 anos em comparação com o design e a funcionalidade dos telefones celulares.
Alcançar a mesma funcionalidade de um telefone celular é apenas um marco, não nosso objetivo. Os veículos podem desenvolver funções muito além dos telefones celulares (como a direção autônoma).
As atualizações de firmware ou software over-the-air (FOTA/SOTA) são um primeiro passo, mas não são inovadoras: elas foram exploradas em áreas relacionadas para telefones e computadores. A questão é qual benefício a atualização cria para o usuário final. Se a função ou aparência de 2 anos atrás for mantida, é provável que desaponte os clientes.
OEMs e fornecedores de nível 1 precisam aumentar a velocidade de desenvolvimento e entrega de software para acompanhar as inovações em outros setores, como telefones celulares. Além disso, os carros são bens de consumo de última geração. Eles têm o potencial de corresponder a expectativas mais altas do que apenas estar no mesmo nível de outras indústrias.
Para OEMs, os custos de desenvolvimento de software devem ser menores e o tempo de lançamento no mercado deve ser mais rápido. Tudo isso será possível se as principais partes do software (a parte que vai agradar o cliente final e a parte que hospeda serviços de terceiros) puderem rodar em um ambiente não seguro. Ao mesmo tempo, a aquisição de hardware precisa ser mais fácil (pelo menos para hardware executado em ambientes não seguros) e reduzir o uso de SoCs específicos para automóveis.
Dessa forma, os OEMs podem oferecer novos serviços a seus clientes e ao ecossistema de terceiros. Grande parte do sucesso do smartphone se deve ao ecossistema de aplicativos e serviços de terceiros oferecidos pela plataforma (ou seja, o smartphone e sua loja de aplicativos).
A mentalidade de uma empresa de software integrada
Enquanto a indústria automotiva está explorando a transição de carros definidos por hardware para carros definidos por software, é importante entender a diferença entre os dois:
• O projeto de hardware geralmente é econômico: como uma alteração de hardware pode ser feita para reduzir o custo em US$ 1? Economizar US$ 1 por dispositivo economiza US$ 1 milhão em 1 milhão de dispositivos.
• O software geralmente tem um fator de escalabilidade: como podemos fazer uma solução de software funcionar para milhões de usuários? Cobrar US$ 1 por usuário por mês pode gerar US$ 1 milhão em receita.
Há uma diferença essencial entre os dois.
As montadoras tradicionais se aprofundaram em listas de materiais para equipamentos de hardware. Os carros exigem especificações claras e detalhadas durante o desenvolvimento. Para atender aos requisitos de especificação, os fabricantes selecionaram o hardware mais econômico. Em última análise, o veículo é limitado por esse hardware até certo ponto, e esse efeito continua durante todo o seu ciclo de vida.
Empresas como a Tesla tendem a escolher soluções de hardware mais poderosas. Mas isso não significa que eles não prestem atenção ao custo BOM. Eles têm maior liberdade para considerar fatores de vantagem competitiva. A Tesla até introduziu jogos dentro do sistema carro-máquina. Esses jogos não se referem a jogos no dispositivo de entretenimento a bordo, mas a jogos que precisam ser jogados em casa com um laptop para jogos. Seria possível fornecer jogos no carro? Talvez não, mas esse não é o ponto da questão. A questão é: os clientes ficarão satisfeitos se conhecerem esse recurso? Porque em qualquer caso, a satisfação do cliente é mais importante do que a função em si.
Esses hardwares e sistemas em chips são mais caros, mas novos recursos são implantados a cada ano, o que também oferece vantagens adicionais para atrair clientes. Mais uma vez, a satisfação do cliente é um fator-chave. E, com certeza, a maioria dos clientes preferiria um carro com recursos cada vez melhores: isso lhes daria a novidade de comprar um carro novo regularmente. De fato, essa escolha resultaria em custos de lista de materiais maiores em comparação com soluções SoC de baixo custo. Mas cada OEM fez escolhas estratégicas, como curvar formas complexas de portas, adicionar um spoiler traseiro retrátil, usar aros de roda específicos… escolhas que ajudam a diferenciar seus produtos e estabelecer as respectivas percepções de marca. Alguns OEMs acreditam que o poder computacional do hardware e software do veículo pode efetivamente melhorar a satisfação do cliente.
Mas há outro fator interessante: 30 anos atrás, quando um fabricante produzia um dispositivo eletrônico, telefone celular ou veículo, gastava zero em hardware eletrônico durante a vida útil do produto. Mas a situação é muito diferente agora, porque o software desempenha um papel importante nesses dispositivos. Hoje, os clientes esperam ver novos recursos de produtos constantemente sendo introduzidos e a segurança do sistema precisa ser mantida, resultando em despesas anuais relacionadas a software. Portanto, além do custo da lista de materiais do hardware, o custo total de propriedade (TCO) da arquitetura elétrica e eletrônica também precisa ser avaliado e otimizado. Reduzir a complexidade do sistema será a chave para reduzir os custos de manutenção.
Finalmente, a seleção de um OEM baseado principalmente em uma arquitetura de componentes de prateleira com requisitos mínimos para adequação automotiva (por exemplo, exigindo apenas a qualificação AEC-Q100 e disponibilidade estendida do produto no lado da CPU) será mais receptivo à escassez de aquisição: isso não apenas em termos de fichas, mas também em engenharia e recrutamento.
Prepare-se para o desenvolvimento futuro
Os fabricantes de equipamentos originais vêm se esforçando há décadas para criar produtos superiores de motores de combustão interna, bem como seus respectivos posicionamentos e identidades de marca, mas recentemente descobriram que a situação é muito diferente: novas marcas nascem, carros mais rápidos e dinâmicos são no mercado. Carros elétricos, e eles são extremamente lucrativos (em termos de capitalização de mercado e lucros da Tesla). Para atender a essas mudanças de mercado, eles lançaram várias iniciativas. Mas eles só podem cumprir verdadeiramente as resoluções de hoje se precisarem manter os veículos implantados em um determinado campo no futuro. Nossas recomendações foram elaboradas para ajudar os OEMs e seus fornecedores a tomar as decisões corretas para um futuro sustentável.