DO-178C: qué es y cómo se certifica el software aeronáutico

Aeroespacial y Drones
octubre 14, 2026

Cuando alguien busca DO-178C casi nunca busca la definición. Busca entender qué le van a pedir: cuántos documentos, qué nivel le toca, por qué su jefe de proyecto insiste con la trazabilidad y qué significa exactamente eso del MC/DC que aparece en el plan de verificación. Este artículo responde a eso, en el orden en el que aparece en un proyecto real.

Qué es DO-178C

DO-178C —en Europa, ED-12C— es el documento de referencia para el desarrollo de software embarcado en aeronaves. Su título completo es Software Considerations in Airborne Systems and Equipment Certification, lo publicaron conjuntamente RTCA y EUROCAE en 2011, y sustituyó a la versión B de 1992.

Conviene empezar por lo que no es, porque ahí está la mayoría de los malentendidos. DO-178C no es un estándar de codificación: no dice cómo escribir el software ni qué lenguaje usar. No es tampoco una certificación que se obtenga: no existe un «software certificado DO-178C» por sí solo, porque lo que se certifica es la aeronave o el equipo, y el software forma parte del expediente. Y no es una norma de calidad genérica del tipo ISO 9001.

Lo que DO-178C define es un conjunto de objetivos que hay que cumplir y, sobre todo, la evidencia que hay que generar para demostrar que se han cumplido. Dicho de otra forma: no basta con hacer bien el trabajo, hay que poder demostrarlo documentalmente ante un auditor que llegará meses después y que no estuvo cuando se tomaron las decisiones.

De dónde sale el nivel: la cadena de seguridad

El nivel de exigencia no se elige: se deriva. Y se deriva de arriba abajo, desde la aeronave hacia el componente.

El punto de partida es el análisis de seguridad del sistema, que se hace siguiendo ARP4754A para el desarrollo y ARP4761 para la evaluación de seguridad. Ese análisis identifica las failure conditions: qué pasa si una función falla, y con qué gravedad. La clasificación es la que se usa en toda la industria:

Catastrófica: impide la continuación segura del vuelo y el aterrizaje.
Peligrosa (hazardous): reduce mucho los márgenes de seguridad o la capacidad de la tripulación.
Mayor: reduce los márgenes de forma significativa y aumenta la carga de trabajo.
Menor: molestia operativa sin consecuencias de seguridad relevantes.
Sin efecto.

De esa clasificación sale el DAL (Design Assurance Level) del software: A para condiciones catastróficas, B para peligrosas, C para mayores, D para menores y E cuando no hay efecto sobre la seguridad. El nivel E no tiene objetivos aplicables, aunque sí hay que justificar por qué se ha clasificado así.

Esta es la primera lección práctica: el coste del software se decide en la arquitectura del sistema, no en el software. Separar una función crítica de una que no lo es, o introducir una partición robusta, puede bajar un nivel entero a la mitad del código. Esa decisión se toma al principio y después ya no se puede deshacer sin rehacer el proyecto.

Cuántos objetivos tiene cada nivel

El anexo A de DO-178C recoge los objetivos en tablas, y es donde se mide de verdad la diferencia entre niveles:

Nivel A: 71 objetivos, de los cuales 30 requieren independencia.
Nivel B: 69 objetivos, 18 con independencia.
Nivel C: 62 objetivos, 5 con independencia.
Nivel D: 26 objetivos, 2 con independencia.

«Con independencia» significa que quien verifica no puede ser quien desarrolló. No exige necesariamente otra empresa ni otro departamento, pero sí otra persona, y hay que poder demostrar quién hizo qué. En equipos pequeños este es uno de los primeros problemas organizativos que aparece.

Fíjate en que entre nivel C y nivel B hay solo siete objetivos de diferencia, pero la independencia pasa de 5 a 18. El salto de esfuerzo no está en el número de objetivos, sino en cómo hay que cumplirlos.

Los procesos: qué se hace y en qué orden

Planificación

Antes de escribir una línea de código se escriben los planes. Son cinco documentos y la autoridad los revisa pronto, porque definen el contrato de lo que vas a hacer:

PSAC (Plan for Software Aspects of Certification): el documento que presenta el proyecto a la autoridad.
SDP (plan de desarrollo), SVP (plan de verificación), SCMP (gestión de configuración) y SQAP (aseguramiento de calidad).

Además se acuerdan los estándares de requisitos, de diseño y de codificación. El error clásico aquí es copiar los planes de otro proyecto sin adaptarlos: en la auditoría se comprueba que lo que dicen los planes es lo que se está haciendo, y una desviación no declarada sale más cara que una práctica imperfecta pero documentada.

Desarrollo

El desarrollo baja por niveles: requisitos de alto nivel, arquitectura, requisitos de bajo nivel, código fuente y código ejecutable. Cada nivel tiene que ser trazable al anterior y al siguiente. Lo que en otros sectores sería documentación «de apoyo», aquí es el producto.

Verificación

La verificación en DO-178C no es «probar el software». Es demostrar, para cada objetivo, que se cumple. Se combinan revisiones, análisis y pruebas, y cada técnica cubre objetivos distintos. Las revisiones de requisitos y de diseño cubren cosas que ninguna prueba puede cubrir, y los análisis —de pila, de tiempo de ejecución, de flujo de datos— cubren otras.

Procesos integrales

Gestión de configuración, aseguramiento de calidad y enlace con la certificación acompañan a todo lo anterior de principio a fin. La gestión de configuración es la que permite responder a la pregunta que siempre llega: «¿con qué versión exacta de qué fuentes, qué compilador y qué opciones se generó este binario?».

Trazabilidad: el núcleo de todo

Si hay un concepto que resume DO-178C es este. Hay que poder recorrer la cadena completa en los dos sentidos:

requisito del sistema → requisito de alto nivel → requisito de bajo nivel → código → caso de prueba → resultado de prueba

Hacia abajo, para demostrar que todo lo que se pidió está implementado y probado. Hacia arriba, para demostrar que no hay código que no responda a ningún requisito. Ese segundo sentido es el que pilla a los equipos nuevos: cualquier función «por si acaso», cualquier resto de depuración y cualquier optimización no pedida es dead code o deactivated code, y hay que justificarla o eliminarla.

Cobertura estructural y MC/DC

La cobertura estructural mide qué partes del código han ejecutado las pruebas basadas en requisitos. Importante: no se escriben pruebas para alcanzar cobertura; se escriben pruebas a partir de los requisitos y después se mide la cobertura. Si falta cobertura, eso señala un problema: o falta un requisito, o sobra código, o faltan casos de prueba.

Lo exigido depende del nivel:

Nivel C: cobertura de sentencias.
Nivel B: además, cobertura de decisiones.
Nivel A: además, MC/DC (Modified Condition / Decision Coverage).

MC/DC es el que asusta, y conviene entenderlo bien porque condiciona cómo se escribe el código. Exige demostrar que cada condición booleana dentro de una decisión afecta por sí sola al resultado, manteniendo las demás fijas. Para una decisión con N condiciones independientes bastan N+1 casos bien elegidos, no 2^N. La consecuencia práctica es inmediata: las condiciones compuestas larguísimas multiplican el trabajo de prueba, así que en nivel A se escriben decisiones simples. La norma acaba moldeando el estilo de programación.

Los suplementos: DO-330, DO-331, DO-332 y DO-333

Una de las novedades de la versión C es que los enfoques modernos dejaron de ser una excepción negociada y pasaron a tener su propio documento:

DO-330: cualificación de herramientas. Si una herramienta automatiza una actividad y sus errores pueden pasar inadvertidos, hay que cualificarla. El nivel de cualificación (TQL-1 a TQL-5) depende de qué pasaría si la herramienta fallara.
DO-331: desarrollo basado en modelos. Cómo encaja un modelo que es a la vez especificación y origen del código generado.
DO-332: orientación a objetos y técnicas relacionadas. Herencia, polimorfismo y gestión dinámica de memoria, con sus riesgos específicos.
DO-333: métodos formales. Cuándo una demostración formal puede sustituir a una prueba, y con qué condiciones.

Dónde encaja DO-178C con el resto

DO-178C no se aplica aislada. En un programa aeronáutico convive con:

ARP4754A, que gobierna el desarrollo de la aeronave y de los sistemas, y de donde salen los requisitos y los niveles.
ARP4761, que aporta los métodos de evaluación de seguridad: FHA, PSSA, SSA, árboles de fallos y análisis de modos de fallo.
DO-254, el equivalente para el hardware electrónico complejo: FPGA, ASIC y similares.
Los requisitos de certificación aplicables, CS-23, CS-25, CS-27 o CS-29 según el tipo de aeronave.

Esta cadena completa se trabaja en el máster de Part-21, CS-23/25/27/29 y DO-178C/DO-254, que es donde se ve cómo un requisito de certificación acaba convertido en un caso de prueba concreto.

Los cinco errores que más se repiten

Empezar a programar antes de cerrar los requisitos de bajo nivel. El código que nace sin requisito es código que después hay que justificar o tirar.
Requisitos no verificables. «El sistema responderá rápidamente» no es un requisito; «el sistema responderá en menos de 50 ms al 99 % de las peticiones» sí lo es.
Confundir cobertura con calidad. Llegar al 100 % de MC/DC con pruebas escritas para alcanzar cobertura, en lugar de para verificar requisitos, es exactamente lo que la norma intenta evitar.
Usar herramientas sin cualificar. El generador de código, el analizador de cobertura y el compilador no son neutrales: si automatizan una actividad de la norma, entran en DO-330.
Dejar el dossier para el final. La evidencia se genera mientras se trabaja. Reconstruirla meses después cuesta más que haberla ido guardando y, además, suele ser imposible.

Qué perfil contrata la industria

Los puestos que piden DO-178C explícitamente suelen ser de ingeniero de software embarcado crítico, ingeniero de verificación y validación, responsable de aseguramiento de software y enlace de certificación. Contratan fabricantes de aeronaves, proveedores de equipos de a bordo, ingenierías de desarrollo y organizaciones de diseño aprobadas.

Lo que marca la diferencia en una entrevista no es recitar los niveles, sino saber contar cómo se construye la trazabilidad, qué pasa cuando aparece un hallazgo en auditoría y cómo se justifica una desviación. Eso solo se aprende trabajando sobre casos reales.

Qué entrega el proyecto: los datos de certificación

Un proyecto DO-178C no termina con el binario. Termina con un conjunto de datos de ciclo de vida que se entregan y que la autoridad puede pedir en cualquier momento. Los más conocidos son tres:

PSAC, al principio: qué se va a hacer, con qué nivel, con qué herramientas y con qué desviaciones previstas respecto a la práctica estándar.
SCI (Software Configuration Index): la fotografía exacta de lo entregado. Versiones de cada fuente, del compilador, de las opciones de compilación y de las herramientas. Es lo que permite reproducir el binario dentro de diez años.
SAS (Software Accomplishment Summary), al final: el resumen de lo que realmente ocurrió, incluidas las desviaciones respecto al PSAC y los problemas abiertos que se aceptan con justificación.

Entre medias quedan los requisitos, el diseño, el código, los casos y procedimientos de prueba, los resultados, los informes de revisión, los registros de problemas y los registros de control de calidad. Todo ello bajo control de configuración, con niveles CC1 y CC2 que determinan cuánto rigor necesita cada elemento.

Una forma útil de verlo: si mañana entra un ingeniero nuevo y tiene que demostrar ante la autoridad que el software es correcto, ¿tiene todo lo que necesita sin preguntar a nadie? Si la respuesta es no, el dossier no está terminado, por muy bien que funcione el producto.

Cómo se forma uno para trabajar con DO-178C

El orden que funciona es el contrario al que la gente intenta. Lo habitual es empezar por la tabla de objetivos y perderse; lo que funciona es entender primero de dónde sale el nivel —es decir, el análisis de seguridad del sistema—, después cómo se estructura la evidencia, y solo al final las técnicas concretas de verificación.

Hay dos razones. La primera es que sin la cadena de seguridad, los objetivos parecen burocracia arbitraria; con ella, cada objetivo tiene un porqué. La segunda es que en una entrevista o en una auditoría nadie pregunta cuántos objetivos tiene el nivel B: preguntan por qué una función concreta es nivel B y no C, y esa respuesta está en el análisis de seguridad, no en la tabla.

Preguntas frecuentes sobre DO-178C

¿DO-178C es obligatoria?

No es una ley, es un medio de cumplimiento aceptado. La autoridad la reconoce como forma válida de demostrar que el software cumple los requisitos de certificación aplicables. En la práctica, en software embarcado en aeronaves certificadas, es el camino que se sigue.

¿Qué diferencia hay entre DO-178B y DO-178C?

La estructura y los niveles se mantienen. Lo que cambia es la claridad de los objetivos, la gestión de las herramientas y, sobre todo, la incorporación de los suplementos para modelos, orientación a objetos y métodos formales, que antes se resolvían caso por caso.

¿Se puede aplicar DO-178C a drones?

Depende de la categoría de la operación y del marco regulatorio aplicable. En operaciones certificadas se aplican enfoques equivalentes; en categorías abierta o específica, los requisitos son distintos y proporcionados al riesgo.

¿Cuánto encarece un proyecto subir de nivel C a nivel A?

No hay un número universal, pero el salto es grande y no viene tanto de los objetivos adicionales como de la independencia en verificación, del MC/DC y de la cualificación de herramientas. Por eso la arquitectura que permite bajar de nivel partes del software es la decisión con más impacto económico de todo el programa.

Formaciones de SEIUM relacionadas con software aeronáutico

Sigue leyendo

Nos entusiasma aclarar todas tus dudas.

¿Necesitas más información o quieres contactarnos? Si tienes alguna duda acá estamos para responderla no tardes en escribir.