Inicio Instrumentación Protección y Seguridad en la conducción asistida y autónoma

Protección y Seguridad en la conducción asistida y autónoma

Frank van den Beuken, de PRQA, analiza el papel que desempeñan la protección y la seguridad en el futuro de la conducción asistida y autónoma

Mayor funcionalidad

Los coches están evolucionando ya que pasan de un dispositivo electromecánico bajo el control de un conductor humano a un vehículo completamente autónomo. En la actualidad nos estamos acercando al punto de inflexión ya que los nuevos coches incorporan en su mayoría sistemas avanzados de asistencia al conductor, como asistente de cambio de carril, frenado autónomo de emergencia, sistemas de visión avanzada y otros, y los coches totalmente autónomos en fase experimental acumulan millones de kilómetros de pruebas.

Los sistemas que proporcionan estas funciones están formados por sensores, accionadores, sistemas radar y lidar que se comunican a través de redes y se controlan mediante microcontroladores, por lo que una definición de un coche es un Internet sobre ruedas. Los coches también se comunican con otros coches (comunicación de vehículo a vehículo o V-V) o con la infraestructura, como semáforos y señales de tráfico (V-I) y con satélites para navegación y generación de informes. Por debajo de todo ello se encuentra, por supuesto, el software: más de 100 millones de líneas de código. Además del código para las aplicaciones, hay sistemas operativos, middleware como pilas de comunicación de redes e interfaces a los sensores, accionadores y hasta la pantalla del conductor.

Mayor vulnerabilidad

Debido a este aumento de la complejidad, los aspectos relacionados con la seguridad y la protección despiertan una mayor preocupación. El crecimiento de la comunicación V-X ha hecho que los coches estén expuestos a ataques exteriores: ya ha ocurrido que un tercero ha tomado el control de un Jeep, imponiéndose al conductor.

El usuario del coche puede añadir una mayor vulnerabilidad. Todos los fabricantes de coches utilizan sistemas de diagnóstico a bordo (On Board Diagnostics, OBD) para supervisor varios parámetros del motor, en busca de averías y para diagnóstico en el taller. El interface del conector (OBD II) es abierto y se busca OBD2 en Google se encuentra un enorme número de conectores OBD con Bluetooth para permitir que el conductor supervise el estado del motor con un teléfono móvil y esto podría abrir el sistema de control del motor a una persona hostil. Un reciente artículo de la Universidad de Michigan describe el uso de la conexión directa entre un ordenador portátil y un OBD para anular las instrucciones del conductor en un camión de gran tamaño y un autobús escolar.

Con una cantidad tan grandes código, la protección también es fundamental. El caso judicial de la aceleración imprevista de Toyota demostró que gran parte del código antiguo no era de alta calidad, por lo que se debe desarrollar código nuevo de mucha mayor calidad.

Estandarización

Solo han pasado cinco años desde que se elaboró el primer estándar específico para protección de coches. ISO 26262 es una adaptación del estándar de protección funcional IEC 61508, que se centra en las necesidades de los sistemas eléctricos y electrónicos instalados en turismos de producción en serie y se aplica a todas las actividades dentro del ciclo de vida de estos sistemas relacionados con la protección, incluyendo los requisitos de calidad del software.

El estándar utiliza los niveles ASIL (automotive safety integrity level) para ofrecer una medida del riesgo asociado a un subsistema. Estos niveles van de A a D, donde A es el nivel de integridad más bajo y D el más elevado, es decir, el más exigente con la mayoría de requisitos. Además de estos ASIL, la gestión de calidad (quality management, DM) de la clase indica que no se le exige el cumplimiento de ISO 26262, lo cual significa que queda a discreción de la organización de desarrollo garantizar la calidad.

Los parámetros de gravedad del riesgo, probabilidad de exposición y controlabilidad determinan el ASIL. El parámetro de controlabilidad exige una atención especial. Se da por supuesto que el conductor está en las condiciones apropiadas para conducir, que cuenta con la formación adecuada para la conducción (permiso de conducir) y que cumple toda la normativa legal aplicable, incluyendo los requisitos correspondientes para evitar riesgos con otros participantes en el tráfico: el conductor debe cumplir las leyes de tráfico. Es necesario adaptar las leyes, de manera que cuando esté en funcionamiento un sistema de conducción automática, el conductor no tenga que prestar atención a menos que el sistema solicite la intervención del conductor. El funcionamiento correcto de la notificación al conductor y la solicitud del control humano es fundamental. Si falla la notificación, es posible que el conductor humano no esté prestando atención y no podrá evitar el peligro, como puede haber sucedido en el reciente accidente de Tesla. Si falla la solicitud, el sistema podría seguir ejerciendo el control en lugar de permitir que el conductor intervenga y evite el peligro.

Estas situaciones siempre se deben asignar a la clase de controlabilidad más elevada (C3), lo cual significa que menos del 90% de los conductores u otros participantes en el tráfico generalmente sean capaces, o apenas capaces, de evitar el peligro. La Parte 6 del estándar 26262 está dedicada al proceso de desarrollo de software para producir código lo suficientemente fiable como para ejecutar un sistema y cumplir el nivel de ASIL necesario. El estándar J3016 de la SAE (Society of Automotive Engineers) divide la automatización de la conducción en seis clases, desde no automática hasta totalmente automática.

Lo sistemas de conducción automática, definidos por la SAE como nivel 3 o superiores, se basan en software para recoger datos de los sensores con el fin de crear un modelo del entorno y a continuación, en función del objetivo, decidir sobre cómo asistir al conductor o controlar el vehículo. También tiene otras tareas críticas, como determinar si los sensores funcionan correctamente, cuándo avisar al conductor y cuándo activar la solicitud de control humano. Es vital que este software responda de manera fiable. Otras tareas del software, como el modelado de los datos del sensor, podrían ser menos críticos pero incluso para ello será necesario analizar el riesgo.

Legislación

Será necesario cambiar las leyes de tráfico para dar cabida a los sistemas de conducción automática, especialmente en el ámbito de responsabilidad y la privacidad. Cada país tiene sus propias leyes de tráfico y existen iniciativas legislativas en numerosas jurisdicciones. En EE.UU., la National Highway Traffic Safety Administration ha propuesto un sistema de clasificación formal que define cinco niveles que van desde el control completo del vehículo por parte del conductor en todo momento hasta la adopción por parte del vehículo de todas las funciones críticas de protección durante todo el trayecto, sin que esté previsto que el conductor controle el vehículo en ningún momento.

Cada estado ha realizado una propuesta diferente: Nevada fue el primer estado en autorizar la circulación de vehículos autónomos para poner a prueba la tecnología de conducción autónoma en vías públicas en 2011, seguido de California, Florida, Michigan, Dakota del Norte, Tennessee y Washington DC. En enero de 2014 se puso en marcha el proyecto europeo de investigación denominado Automated Driving Applications & Technologies for Intelligent Vehicles, que desarrolla varias funciones de conducción automática para el tráfico diario mediante la adaptación dinámica del nivel de automatización a la situación y al estado del conductor. El proyecto también cubre los aspectos legales que podrían influir sobre una comercialización exitosa.

Vehicle & Road Automation (VRA) es una iniciativa de apoyo financiada por la Unión Europea para crear una red de colaboración formada por expertos y otras partes interesadas que trabajen en el despliegue de vehículos automáticos y su infraestructura relacionada. VRA colabora con algunos fabricantes de equipos originales (OEM) y suministradores, pero los miembros son en su mayor parte institutos de investigación y universidades. VRA ha identificado una lista de aspectos legales y normativos en la UE. Volkswagen ha apelado a acciones legales colectivas en Europa, incluyendo la modificación progresiva de la Norma 79 de la ECE (también norma de la UN) sobre dirección asistida. Exige que en todo momento el conductor pueda anular la función y conservar el control principal. El gobierno japonés tiene previsto desarrollar leyes para regular el uso de coches sin conductor.

El gobierno también ha creado una clasificación de la conducción automática en cuatro clases, entre ellas una para conducción completamente autónoma. En China, Baidu (a menudo llamado el Google de China) también está trabajando en el desarrollo de un coche automático con BMW. La legislación china es bastante flexible por lo que el gobierno tiene más poder para introducir los cambios necesarios. No obstante, tienen que afrontar unos aspectos tan complejos como en otros países. India también está pensando en la conducción autónoma pero se enfrenta a grandes retos, como la lenta legislación y la dificultad para imponer las normas previstas debido a la diferente infraestructura.

Enfoques para el desarrollo

En este contexto, ¿cómo crear código protegido y seguro? Como se ha dicho antes, ISO 26262 propone un proceso para el desarrollo de software que incluye el uso de estándares de codificación y herramientas de comprobación de código. La seguridad del sistema empieza por el diseño de funciones que contribuyan a ofrecer un resultado seguro, como son: la separación de la aplicación, y en concreto la división mediante cortafuegos de aplicaciones críticas de protección (como dirección y frenos) respecto a las menos críticas, sobre todo las que se comunican con el mundo exterior (como infoentretenimiento); limitación de la comunicación; comprobación y validación de los datos que se comunican; entre otras. Dado que la mayoría del software en este ámbito está escrito en C, un buen punto de partida para un código protegido y seguro es MISRA C:2012 (MISRA 3).

Éste proporciona un conjunto de recomendaciones para escribir programas en C y que, además de evitar un comportamiento indefinido, incluye reglas que mejoran el mantenimiento, la comprobación, la portabilidad y la legibilidad del código fuente. También existe una amplia coincidencia entre las reglas de MISRA y las tablas de cumplimiento de ISO 26262-6, por lo que MISRA es una opción aconsejable cuando se exija el cumplimiento de ISO 26262. MISRA ha publicado recientemente la modificación 1 de MISRA 3. Ésta tiene 14 reglas nuevas que amplían la cobertura de MISRA al desarrollo de sistemas seguros. Las herramientas constituyen una parte importante del desarrollo en cumplimiento de 26262. Las herramientas de análisis estático de código son una parte importante de la gestión de calidad del código ya que proporcionan control de calidad del código y miden su grado de cumplimiento de los estándares de codificación, como MISRA.

Las herramientas de prueba ofrecen una confianza aún mayor en el software, mientras que las herramientas de verificación miden si el software cumple los objetivos del diseñador. Es posible desarrollar sistemas protegidos y seguros para vehículos y las organizaciones que han remodelado sus procesos de desarrollo para cumplir ISO 26262 han descubierto que, tras una fase inicial de introducción y aprendizaje, también logran aumentar su productividad.

Referencias

http://www.iso.org/

http://www.iec.ch/functionalsafety/

http://www.sae.org/

http://www.nhtsa.gov/

https://www.adaptive-ip.eu/

http://vra-net.eu/

https://www.unece.org/

https://www.misra.org.uk/