Autor: pabloantonino

Elicitação de Requisitos de sistemas Safety-critical

pabloantonino Embedded, Tudo , ,

Sistemas safety-critical são aqueles que, em caso de falha, podem causar danos severos ou morte de indivíduos e/ou danos significativos ao meio ambiente. Esses sistemas estão presentes em diversos equipamentos que fazem parte do nosso cotidiano, como, por exemplo, carros (e.g. sistema de controle de frenagem, controle de piloto automático, ajuste de tração), aviões (e.g. sistema de controle de porta, sistema de ajuste de rota, navegação), e equipamentos médicos (e.g. sistema de ajuste de radiação em maquinas de ressonância magnética, sistemas de gatilho de marca-passo).

 IEEE_logoVocê já se perguntou como os requisitos desses sistemas são elicitados e documentados? As regras para tratar requisitos de safety são um tanto quanto diferentes das praticas “tradicionais” de elicitição de requisitos. Para que os produtos sejam homologados, e então liberados para o mercado, os equipamentos tem que ser desenvolvido seguindo praticas descritas em padrões ISO/IEEE (e.g. ISO 26262, ISO 14971). Esses padrões cobrem práticas que vão da especificaçao até à implantação do sistema. Nesse post vamos tratar apenas dos itens que são comuns à fase de requisitos de sistemas safety-critical.

Processos de elicitação de requisitos de safety, em geral, seguem 5 passos:

1 – Identificação do ítem: Considerando o domínio automotivo, o item não é o carro em si; mas um sistema que, ao final, irá compor o automóvel, como, por exemplo, o sistema de controle de tração, o sistema de piloto automático, etc.

2 – Análise de riscos e ameaças (hazard and risk analysis): Nessa fase são analisados e documentados todos os riscos inerentes àquele sistema. Um exemplo de hazard é “Piloto automático não desativar quando requisitado pelo motorista”. A cada um desses eventos é associado um Safety Integrity Level ou SIL (isso é assunto para outro post), que corresponde a uma indicação do quão catastrófico esse evento pode ser cruise-control-traktor-headercaso aconteça.

3 – Estabelecer Safety Goal: Cada evento ameaçador é associado a um safety goal ou, traduzindo literalmente, meta de segurança. Por exemplo, o safety goal associado ao hazard “Piloto automático não desativar quando requisitado pelo motorista” pode ser “Piloto automático precisa ser desativado quando requisitado pelo motorista”.

4 – Requisitos funcionais de safety: Para cada safety goal, uma série de requisitos funcionais de safety são derivados. Exemplo: “Ao pisar pedal de freio, piloto automático deve ser desativado”.

5 – Requisitos técnicos de safety: Cada requisito funcional de safety deve ter detalhes técnicos de como ele será implementado. Essa especificação deve conter detalhes dos blocos funcionais que vão implementar a função (hardware e/ou software).

normas-iso

No processo de certificação do produto, todos os artefatos e documentos associados são analisados e avaliados quanto a consistência, detalhamento, de modo a julgar a eficácia e eficiência do produto. Uma vez homologado, o produto é liberado para o mercado.

Processos de engenharia de safety são muito complexos e rígidos. Muitas outras técnicas são usadas para assegurar que esses sistemas não falharão. E, caso falhem, que o efeito seja o menos trágico possível.

No próximo post irei escrever sobre o que vem sendo feito no Brasil na área de sistemas safety-critical; mais especificamente no que diz respeito a software embarcado em equipamentos médico-hospitalares.

In-Car Connectivity – Carros Conectados à Internet

pabloantonino Embedded, Tudo

Screen shot 2012-12-20 at 11.47.10No Salão do Automóvel de Frankfurt de 2011, a Ford anunciou o Evos Concept Car. Dentre as inúmeras inovações propostas, uma que se destaca é a interação do carro com serviços disponíveis na nuvem, que pretende transformar a maneira que guiamos. A idéia geral é apresentada por Paul Mascarenas – Ford Chief Technical Officer and Vice President Research and Innovation -, e pode ser assistida no vídeo disponível nesse link. Muito marketing vem sendo feito sobre o Evos; em especial, o 2012 Sydney Motor Show deu grande destaque ao conceito de automotive cloud connectivity. No entanto, pouco se vê se concretizando. Mais informações sobre o Evos pode ser encontrada aqui.

ericsson_logo

Quem parece que vai concretizar essa história de In-Car Connectivity é a Volvo e a Ericsson. No último dia 17/12/2012, a Ericsson anunciou uma parceria com a Volvo que promete conectar carros com serviços disponíveis na nuvem. O anúncio pode ser lido na íntegra aqui. Desde então, o assunto tem sido muito comentado; por exemplo, Volvo and Ericsson Partner for In-Car Connectivity, e Ericsson e Volvo Lançam Carro Conectado na Nuvem. 

O que vi e ouvi na 64th Feira de Veículos Comerciais em Hannover

pabloantonino Embedded, Tudo , ,
Entre os dias 20 e 27 de Setembro, o Hannover Messe sediou a 64th feira de veículos comerciais, IAA 2012(Internationale Automobil-Ausstellung). Esse evento reúne os principais produtores de veículos de grande porte como caminhões, carretas, utilitários de menor porte como vans e combos, assim como produtores de peças e tecnologias para veiculos dessa categoria.Tive boas conversas com gente da Mercedes, Volvo, Bosch, BorgWarner, Donaldson, e alguns outros nomes desse mercado. Foi bom ver as novidades, e, claro, a evolução do software nesses produtos. Os hot-topics foram: comunicação carro-a-carro, personalização, integração com smart phones, e ampla integração com redes sociais. Em especial, a Bosch estava mostrando um sistema que permite personalizações em um caminhão, com base na sincronização entre o iPhone do motorista e o sistema central do veículo. Mais especificamente, antes de entrar no caminhão,  o motorista iniciava um app, e algumas configurações como regulagem de bancos e espelhos, e o esquema de cores do painel eram ajustados.

No que diz respeito a redes sociais, as preferências de restaurantes e localização de amigos, por exemplo, também fazem parte desses sistemas. Se em determinado momento o motorista iniciar uma busca de restaurantes próximos se sua localidade, o sistema dará destaques especiais a restaurantes que tenham similaridades com as preferências dele definidas em redes sociais, e mostrará como esses locais tem sido avaliados pelos demais clientes.

No que tange desenvolvimento desses sistemas, todos destacaram que o fato do software ter assumido papel chave nesse contexto foi importante, tendo em vista todo beneficio gerado. No entanto, os efeitos colaterais tem sido grandes. O principal problema destacado foi: Atraso na entrega do produto. Os cronogramas de projetos desses sistemas nunca estiveram tão atrasados. E todos culpam os times de desenvolvimento de software. Aquela velha historia que ouve-se frequentemente “a culpa é do pessoal da informática” se tornou comum nesse meio.

Muitos destacaram a necessidade de contratação imediata de profissionais qualificados para atuar no desenvolvimento de sistemas dessa natureza. As demanda são diversas: gerenciamento de requisitos, modelagem arquitetural, teste, controle de evolução,  gerência de configuração, e gerenciamento de projetos foram enfaticamente citados.

O mercado está aquecido. Apesar da crise na europa, as empresas tem contratado engenheiros de software aos montes. Aos interessados, se dediquem a aprender inglês. Sem ele todo conhecimento adquirido com métodos e técnicas computacionais não terão valia alguma por aqui.

Carros Inteligentes

pabloantonino Embedded, Tudo ,

O avanço das técnicas computacionais vem motivando a indústria automotiva a praticamente reinventar os seus produtos, fazendo com que os carros de hoje em dia sejam, de fato, um aglomerado de sistemas de computação se comunicando e tomando decisões que, em certos casos, chegam a ser superiores às intenções dos motoristas.

Para se ter noção da quantidade de computação presente em um carro nos dias de hoje, considere os seguintes dados: Um jato F-35 contém aproximadamente 6 milhões de linhas de código; um 787 Dreamliner, 7 milhões. Já um Mercedes-Benz classe S, aproximadamente 20 milhões de linhas de código. Em 2009, a Frost & Sullivan estimou que em um futuro não muito distante, os carros chegarão a 300 milhões de linhas de código.

Quais as implicações de tanta computação em um automóvel? Uma das principais, obviamente, é o custo de produçao. O Dr. Manfred Broy, professor de Ciência da Computação da TU Munique, e mentor para assuntos computacionais de uma renomada marca automotiva alemã, estima que o custo com software e eletrônicos em um carro chega a ser responsável por ate 40% do custo de um automóvel. Nos proximos sete anos, essa porcentagem deve chegar a até 80%. Levando em conta que a hora de profissionais de software nao é nem um pouco barata nos dias atuais (Good for us! :-)), espera-se que a contínua necessidade desses profissionais no desenvolvimento de carros eleve ainda mais os preços destes num futuro próximo. No contexto brasileiro, isso implica em carros ainda mais caros. Dai vê-se a necessidade de um ajuste na política de preços no setor automotivo brasileiro.

Diante desse cenário, os grandes nomes da computação têm voltado a atenção para o mercado automotivo: Microsoft firmando acordo com Toyota, a Google e seu Google Car, IBM, e até a Apple sonha sonhou em se aventurar no mercado automotivo com o utópico iCar.

Gostaria de compartilhar algumas experiências pessoais sobre os desafios no dia-a-dia no ambiente de desenvolvimento em algumas indústrias automotivas. Mas isso é assunto para outro post.

Aos interessados, recomendo a leitura do artigo This Car Runs on Code de  Rober N. Charette, fonte primária das informações desse post.

Modelos Arquiteturais em Sistemas Aviônicos

pabloantonino Embedded, Tudo , , , ,

   Antes de me aventurar no domínio de sistemas embarcados, trabalhei com desenvolvimento de sistemas financeiros e de administração público-privada. Diversas vezes, ao perguntar por modelos arquiteturais do sistema, era informado que ele era inexistente estava desatualizado. Depois de algum tempo nesse contexto, me juntei ao grupo de profissionais que acreditam que um bom código fonte e algumas linhas de comentário são suficientes enquanto documentação.

A realidade no domínio de embarcados é bem diferente. Entidades que regulamentam sistemas que, em caso de falha, causarão danos à pessoas ou ao meio-ambiente (mais conhecidos como sistemas safety-critical), exigem que as empresas que constroem esses sistemas sigam rigidamente as etapas dos processos de desenvolvimento, e gerem artefatos de documentação extremamente detalhados.

No caso de sistemas aviônicos, o DO-178B – Software Considerations in Airborne Systems and Equipment Certification, por exemplo, define processos rígidos para (i) Planejamento, (ii) Desenvolvimento, (iii) Requisitos, (iv) Design, (v) Codificação e Integração, (vi) Teste e Verificação, (vii) Gerencia de configuração, e (viii) Gerenciamento de qualidade. Para se ter uma ideia geral das etapas e artefatos, recomendo uma olhada na seguinte apresentação: Introduction to Avionic Systems Development.

Um dos artefatos exigidos pelo DO-178B é a documentação arquitetural dos vários sistemas que compõe um sistemas aviônico: diagramas de componentes, diagramas comportamentais de tempo-continuo e de estados, dentre outros.

Alem de servir para documentação, esses modelos são usados como base para geração de código funcional. Essa historia de geração automática de código soava um tanto quanto utópica para mim também, até que, certa vez, o chefe da engenharia de uma grande empresa de aviação me disse que não confiava em códigos escritos por desenvolvedores, mas sim em códigos gerados a partir de especificações arquiteturais. Tentando entender o que se passava na cabeça desse cidadão, comecei a me inteirar mais sobre o assunto, e me convenci do quão poderosos mecanismos de geração de código podem ser quando utilizados apropriadamente. Para uma visão prática sobre o assunto, recomendo conhecerem um pouco sobre ferramentas como OpenArchitectureware e Acceleo.

Esses modelos são também peças-chave nos processos de garantia de qualidade, que vão desde testes baseados em modelos à técnicas formais de Model-Checking (sim, estou falando de assuntos relacionados a métodos formais. Eles são amplamente utilizados na industria aviônica). Toda essa amarração exigida pelas normas regulatórias implica em lentidão no desenvolvimento, e, quando não gerido adequadamente, pode gerar atrasos consideráveis na entrega do produto (ver caso do Boeing 787 Dreamliner). No entanto, empresas que desenvolvem esses produtos muitas vezes optam por atrasos aceitáveis no time-to-markt, mas assegurar que os produtos são feitos como manda a norma; caso contrário, o prejuízo financeiro será ainda maior, e a reputação da empresa desaparece.

Aí vai um recado para turma do “anti-modelos-e-apenas-código-escrito-é-o-que-conta”: Sistemas dessa natureza não podem falhar! Não existe possibilidade de reiniciar o sistema de navegação ou de propulsão de uma aeronave enquanto ela voa a 900Km/h a uma altitude de 30000 pés. O custo de voltar a versão de um software depois que ele já foi inserido em uma família de jatos tem um custo que pode comprometer o projeto como um todo. Não estamos tratando de sistemas web; também não quero dizer que estes sejam menos complexos ou de menor importância; digo apenas que as restrições de domínio são mais rígidas, levando em conta as catástrofes causadas se um sistema desse falhar.

Embedded Systems no BdB

pabloantonino Embedded, Tudo

Estamos iniciando hoje uma coluna que tratará exclusivamente de assuntos relacionados ao desenvolvimento Sistema embarcados (embedded systems). O objetivo deste primeiro post é destacar a relevância do assunto, uma vez que muitos podem estar se perguntando o porque de uma coluna exclusiva para tratar deste tema.

No passado, o termo embedded ou embarcado remetia à projetos impressos em placas de circuito que ofereciam uma ou duas funcionalidades. Hoje o termo tomou uma proporção bem maior, uma vez que grande parte de nossas atividades diárias dependem de equipamentos que são controlados por algum tipo de sistema embarcado. Um automóvel, por exemplo, possui sistemas responsáveis pelo controle de frenagem, cálculo de consumo de combustível, piloto automático, navegação, dentre outros. Em equipamentos médico-hospitalares, como em uma maquina Raio-x, existem sistemas embarcados que garantem que o paciente não receberá dosagens extremas de radiação. Um avião é quase que absolutamente controlado por sistemas complexos que funcionam de maneira altamente integrada, de modo a garantir a devida execução de comandos.

Profissionais que projetam e desenvolvem esses sistemas, além de considerarem os aspectos funcionais, precisam levar em conta restrições do domínios impostas por entidades reguladoras como ISO e IEEE. Essas restrições determinam, por exemplo, o processo de desenvolvimento a ser seguido, mecanismos de testes, e níveis aceitáveis de integração entre as parte que compõe os sistemas. Além disso, esse profissionais precisam considerar desde limitações de processamento e memória, à condições ambientais extremas que o sistema estará sujeito, tais como variações de temperatura, humidade e radiação.

Por uma questão histórica, esses sistemas eram desenvolvidos exclusivamente por Engenheiros eletrônicos. No entanto, como o software tem se tornado aspecto chave nesses sistemas, profissionais com formação em Ciência da Computação tem sido cada vez mais requisitados, devido ao conhecimento em métodos e técnicas computacionais exigidos pelos orgãos certificadores.

Essa coluna irá tratar de tópicos do domínio da computação que tem sido utilizado no desenvolvimento de sistemas embarcados, tais como desenvolvimento de sistemas embarcados usando métodos ágeis, frameworks de desenvolvimento, linguagens de programação mais usadas (acreditem, esse mundo não se limita a C/C++), plataformas de desenvolvimento (principalmente no domínio de sistemas automotivos e aviônicos), gerenciamento de projetos e de requisitos, dentre outros.