Software integrado
otro
Software integrado

software de a bordo de aeronaves

 

El propósito principal de los documentos y estándares reglamentarios es proporcionar materiales de orientación para su uso en los procesos de creación de software para sistemas a bordo de aeronaves, que deben realizar las funciones apropiadas con un nivel de confianza en la seguridad que cumpla con los requisitos de aeronavegabilidad de las aeronaves.

Entre los instrumentos internacionales que contengan los requisitos de software de AT es el más importante documento DO-178, formulada por primera vez en 1978 En sus versiones mejoradas de los que actualmente se utilizan: DO-I78A, actuando con la ciudad 1985 y DO-I78B, actuando con 1993 , a la que se presta una atención considerable a la cuestión de la calificación de herramientas de software.

En Ucrania y Rusia, existen análogos de estos documentos: CT, respectivamente 178A con la ciudad y la TC 1998 178 con 2004V, la adición de estos requisitos de elegibilidad son los documentos y la RM-RM-178A 178V.

Entre la serie de normas ISO en vigor en Ucrania y software relacionado está dominado por dos: DSTU ISO-9000 3 98-y-DSTU 3918 1999 (ISO / IEC 12207: 1995). La primera está dedicada a la organización y las actividades del sistema de calidad en relación con el software, los procesos del ciclo de vida del software de la segunda. Los requisitos de las normas ISO directamente relacionados con los procedimientos de certificación de Sun y sus componentes, incluyendo el software de proceso de certificación.

Además, para la certificación de las empresas de la industria aeronáutica, en este caso, los procesos de producción de software de creación y aplicación utilizan APMAK documento "Guía 21.2S", es decir, la sección "Elemento 3. La garantía de la calidad del software ", que se divide en dos partes:" Parte A. A bordo de Software "y" Parte B: programas informáticos de recepción de los productos ".

Software se refiere al software de a bordo de los sistemas electrónicos de las Fuerzas Armadas, que serán una parte integral de la base de certificación de las Fuerzas Armadas de un cierto tipo e instalados a bordo para poner en práctica para la operación de las funciones de sol. Los sistemas de software diseñados, por ejemplo, para la prueba de sol, aunque instalado a bordo de la aeronave no está en el aire, y se refiere al proceso de creación de herramientas de AT.

Dado que las funciones de los sistemas digitales a bordo se implementan a través de software, este último es objeto de especial atención organismo de certificación debido a su impacto directo en la seguridad de operación de la aeronave.

Criticidad de los sistemas de a bordo y funcionales a nivel de software. El objetivo principal de los procedimientos de certificación - es, ante todo, para obtener ciertas garantías de seguridad: prevención de la muerte, lesión, enfermedad, pérdida de la propiedad. El inicio de la certificación para cualquier sistema técnico complejo es analizar las posibles consecuencias de la pérdida (deterioro) de las funciones del sistema de la seguridad de su explotación o uso para los seres humanos y los bienes. Y no importa lo que causó la disfunción - errores de los usuarios, fallos de hardware o errores de diseño de software. Importantes son sistema de control de profundidad, la identificación y la capacidad de parar los medios de rebote del sistema o el sistema de un nivel más alto de la jerarquía, la necesidad de redundancia, la reconfiguración. Para analizar las consecuencias de la violación de las funciones del sistema, como regla general, usted tiene que volver varias veces después de los siguientes pasos, según la definición correcta de la categoría de gravedad depende de los requerimientos de rigidez para el software.

Documento TC 178V define cinco categorías de gravedad de los sistemas funcionales y, por tanto, de cinco niveles de software. A pesar de que, por definición, categorías y niveles de criticidad del software del sistema están conectados de forma rígida, el procedimiento de establecer niveles de desviación admisible en una u otra manera.

los niveles de clasificación de software Categorías de criticidad de la siguiente manera:

  • A nivel de software - en un sistema de este tipo funcional, que la exención del estado, que surgió debido a un error en el software, puede conducir a una situación desastrosa para el sol cuando es prácticamente imposible evitar la muerte del sol y la gente. La probabilidad de que una situación de este tipo, una hora de vuelo a ser casi increíble, es decir, menos de 10 9 ~ ..;

  • Los niveles en el software de un sistema funcional de este tipo, cuya exención del estado, que surgió debido a un error en el software, puede conducir a una situación de emergencia para el Sol situación de emergencia caracterizada por un deterioro significativo de las características del sol o superior a sus restricciones de límite, así como tal estrés físico de la tripulación de vuelo, en la que no puede con precisión y completamente realizar sus funciones. Una situación de emergencia puede provocar daños importantes en el sol, o las lesiones de las víctimas individuales. La probabilidad de una situación tal, una hora de vuelo que sea muy poco probable, es decir, estar en el intervalo de 10 M0 ~ 9 ..;

  • EN nivel de - a un sistema funcional de este tipo, cuya exención del estado, que surgió debido a un error en el software, puede conducir a una situación difícil para el Sol La compleja situación que se caracteriza por una marcada características deterioro del sol, la salida de uno o más parámetros de las limitaciones de operación, pero sin llegar a las limitaciones de carrera y una disminución de la capacidad de la tripulación para hacer frente a esta situación debido a la mayor carga de trabajo y debido a las condiciones desfavorables que reducen la eficiencia acciones de la tripulación . Difícil situación puede causar molestias a los pasajeros, incluyendo la posibilidad de lesiones. La probabilidad de una situación difícil para una hora de vuelo a ser poco probable, es decir, estar en el intervalo de 10 5-10-7 ..;

  • En el nivel D - en este sistema funcional, que la exención del estado, que surgió debido a un error en el software, puede conducir a una complicación de las condiciones de vuelo para las Fuerzas Armadas. Esta situación se caracteriza por un ligero deterioro de las características del sol o de un ligero aumento en la carga de trabajo de la tripulación. Esta situación se puede evitar, por ejemplo, cambiando el plan de vuelo, y para los pasajeros, no debe conducir a más de algunos inconvenientes;

  • En el e - software de un sistema funcional, cuya exención del estado, que surgió debido a un error en el software no afecta a la capacidad operativa de las Fuerzas Armadas y no aumenta la carga sobre la tripulación. Alejándose de la entidad de certificación para confirmar que el software pertenece al nivel E, significa que las disposiciones del documento TC 178V no se aplican a él.

 

Documento TC 178A define tres categorías de funciones críticas a bordo sistemas de la aeronave:

  • esencial si una situación especial que pudiera surgir en violación de la aplicación de al menos una de las funciones de las Fuerzas Armadas del sistema, caracterizado por ser catastróficas o de emergencia;

  • importante si una situación especial que pueda surgir en la aplicación de la violación de al menos una de las funciones de las Fuerzas Armadas del sistema se relaciona con el complejo;

  • insignificante si la situación especial que pudiera surgir en la aplicación de la violación de al menos una de las funciones de las Fuerzas Armadas del sistema se refiere a la complicación de las condiciones de vuelo o no tiene ningún efecto.

 

Por consiguiente, hay tres niveles de software:

  • 1 nivel de la categoría "crítico" con el software más exigentes y la máxima cantidad de trabajo que debe cumplirse con el fin de demostrar el cumplimiento de los requisitos de certificación, y el número máximo de documentos adjuntos;

  • 2 nivel - para la categoría "sustancial" con requisitos más bajos;

  • 3 nivel - para la categoría de "no esenciales" con los requisitos mínimos.

software de nivel no sólo depende de la categoría de funciones críticas. importante papel desempeñado por la arquitectura del sistema y la estructura de su software. Por ejemplo, el sistema puede ser analizado canal analógico espera que duplicar toda la función del canal digital. Bajo ciertas circunstancias, esto puede ser suficiente para disminuir el nivel. Por el contrario, cuando se analizaron en un solo sistema Sun se utiliza de tal manera que su negativa a responder a una categoría crítica, y las otras fuerzas armadas de la misma falla en el sistema conduce a una condiciones de funcionamiento más críticas, el diseñador del sistema puede determinar un nivel más alto. Una influencia importante en la determinación del nivel del software son también métodos para su diseño. por ejemplomedidas, el método de aislamiento o de control como método de protección contra ciertas condiciones de fallo por la validación continua de la función o multi-versionada método, cuya aplicación prevé la creación de dos o más componentes de software que realizan una función de diferentes maneras y con diferentes software proporciona la capacidad de separar funcionalmente independiente componentes de software para aislar los fallos.

Los valores numéricos antes mencionados de la probabilidad de ocurrencia de situaciones especiales no se relacionan con la probabilidad de errores no detectados en el software. El software no se puede aplicar al aparato matemático desarrollado de la teoría de las estadísticas, que ladra posible calcular la probabilidad de eventos, ya que no existe una relación directa entre la probabilidad de ocurrencia de situaciones particulares y no son propensos a detectar errores en el software. Por lo tanto, los niveles de indicadores sobre o fiabilidad, basado en un nivel de software, no se pueden utilizar en la evaluación de la seguridad del sistema, por ejemplo, tal como se utiliza tasa de fallo de hardware.

Sin embargo, las normas recomiendan el uso de estos u otros criterios cuantitativos para evaluar la calidad del software o para lograr un cierto nivel de calidad, teniendo en cuenta el hecho de que la industria del software se ha acumulado una gran colección de modelos y las métricas que permiten evaluar diferentes características del software. Además, durante el desarrollo y verificación de software es muy recomendable para mantener un registro de los errores detectados y desventajas, así como las medidas adoptadas para hacer frente a ellos.

 

Los procesos de desarrollo, verificación y validación de software

El paso principal en la creación de cualquier producto técnico es su diseño, incluyendo la creación de un prototipo, probarlo para verificar el cumplimiento de los requisitos y, al final, la aprobación de su capacidad de servicio. Creación de un producto de software cumple plenamente con estos procesos.

Presenta el proceso de creación de un producto de software de interés desde el punto de vista de la obtención de ciertas garantías de seguridad. Aquí, cada evento asociado con el desarrollo de (P) tiene un evento de verificación correspondiente (B). Y ambos producen los documentos pertinentes (D).

El material inicial para iniciar procesos de desarrollo de software son los requisitos declarados para el sistema, que deben formalizarse en forma de documento adecuado (DF <"cero">), y que deben convertirse en requisitos de software (D1), precisamente por el hecho de que la implementación Las funciones de los sistemas electrónicos digitales, como ya se señaló, se llevan a cabo mediante software. El proceso de desarrollo de requisitos de software (P1) es el proceso de transformar los requisitos del sistema en requisitos de software.

Para facilitar la comprensión del procedimiento de transformación, tanto durante el desarrollo y se recomienda su procedimiento de verificación a dividirse en al menos dos partes: a los requisitos de diseño de alto nivel y las necesidades de desarrollo posteriores bajas.

requisitos de alto nivel directamente derivan del análisis de los requisitos del sistema en vista de las características de su construcción. Es necesario observar las siguientes condiciones: cada requisito de que el sistema debe ser transferido a uno o más de los requisitos para un alto nivel, y viceversa, cada uno para un alto nivel de software - en uno o más de los requisitos del sistema, a excepción de las reivindicaciones derivados que no se derivan directamente de los requisitos del sistema (por ejemplo, procesamiento de interrupción de la demanda, en función de las características de la calculadora de destino seleccionado). Los derivados de requisitos de alto nivel que han de transmitirse en el proceso de evaluación de la seguridad del sistema. Por alto nivel requisitos incluyen requisitos técnicos y funcionales, la interoperabilidad y la demanda de los requisitos de seguridad.

Requisitos de bajo nivel se expresan en términos de ingeniería de software y se obtienen mediante el análisis y detalla los requisitos de alto nivel. Requisitos niveles bajos están directamente relacionados con los procedimientos de codificación y software agregación, t. E. Es los requisitos para la aplicable lenguajes de programación, compiladores, la arquitectura y middleware, a la estructura de sus componentes, a la clasificación de objetos de software a la base del operador, para el medio ambiente, el desarrollo y verificación así como para el estilo de programación.

documentos relacionados son las normas y otros documentos normativos (D2) en las especificaciones técnicas para el diseño, codificación, el apoyo. El ejercicio de verificación, completando la primera etapa de desarrollo, - una comparación de los requisitos para los requisitos del sistema de software con el fin de verificar la compatibilidad de la distribución de funciones entre el hardware y el software y las interfaces, integridad o adecuación de los requisitos para el software. La forma recomendada de documentación - una tabla de referencias cruzadas, que puede ser emitido como una verificación de documentos por separado, o formar parte de un documento general que describe todas las etapas de los procedimientos de verificación y sus resultados, así como los nuevos problemas y medidas para hacerles frente.

Las próximas etapas de desarrollo - los procesos de desarrollo de software y la gestión de su calidad de planificación. El propósito principal de la planificación - la identificación de los recursos y las secuencias de acción, lo que garantiza la consecución de los objetivos. Hay todavía está determinado por los procesos de organización (relación). Como resultado, deben ser emitidos cinco documentos (que se permite una combinación razonable): planes de certificación (DZ), el plan de desarrollo de software, verificación del plan y los planes de gestión de configuración (D6) y garantizan su calidad. Las actividades de verificación (V2, VZ) se refieren principalmente a la coordinación de los procedimientos en la etapa de aprobación de los planes, así como su corrección por los comentarios que surgieron en las últimas etapas de la operación, e incluso software. El contenido de los documentos considerados más.

Continuación del proceso de desarrollo es un proceso de diseño de software. En este caso, los requisitos de software de alto nivel se especifican para un número de iteraciones del proceso de diseño para formar la arquitectura de software de algoritmos de funcionamiento, teniendo en cuenta el bajo nivel de requisitos a tal punto que en ellos era posible hacer que el código fuente. Para satisfacer los requisitos de seguridad debe proporcionar un control de control y flujo de datos, por ejemplo, para proporcionar un temporizador de vigilancia, la comprobación de consistencia y transversal comparación fluyen naturalmente con la reacción correspondiente al estado de "rechazo". Los resultados de diseño se registran en un documento que describa el proyecto.

El ejercicio de verificación V4 - cheques proyecto sobre los requisitos de cumplimiento para el software y los estándares para el diseño, incluyendo la verificación de los algoritmos de operación del sistema. El objetivo principal de la verificación del proyecto es proporcionar su "verificabilidad". Esto debe tenerse en cuenta al menos los siguientes factores: la secuencia de ejecución del programa, los flujos de datos y la posible distorsión de su potencial impacto en las funciones de aislamiento de hardware y de integridad. El documento D13 verificación debe ser una tabla de cumplimiento del proyecto a petición de un software en forma de análisis de la sección transversal. Retirada de las normas y requisitos hay que señalar y justificado.

Todas las etapas hasta el momento, Lager fase de diseño del software puede ser descrito como preliminar. Sólo como resultado del proceso de programación (R5), interconexión de componentes de software (R6) y la integración del software con el hardware (R7) aparece productos de software propios en su forma final.

El primer resultado del proceso de implementación de un requisitos de bajo nivel, siempre es un código fuente (D9), que debe ser transformado en el proyecto. arquitectura de software de contabilidad en el proceso de diseño se implementa en los procedimientos de software de múltiples componentes y software de integración al equipo de destino será en última instancia código ejecutable objeto (DOJ) y el software de configuración de directorio apropiado (D11). datos de entrada incorrectos o insuficientes identificados en estos procesos, es necesario volver a los procesos anteriores para las correcciones o claridad. Además, el entorno de desarrollo de software (que es, con mayor frecuencia, y el medio ambiente de su apoyo) deben ser claramente y completamente definida y fija (D12).

Huelga decir que en esta etapa de desarrollo llevado a cabo el más voluminoso, el más complejo en su contenido y las medidas de verificación más importantes (V5, V6, V7) bajo el título - prueba (test) de software para detectar errores contenidos en el software. El problema aquí es que los errores detectados suelen ser eliminados, no se identificaron ni siquiera puede ser predicho.

El contenido de las tres medidas de verificación.

Este proceso consiste en una serie de iteraciones, e incluye todas las posiciones en cada iteración y para cada evento. Los resultados del proceso se registran en un D13 documento.

Procesos de revisión de desarrollo de software sería incompleta sin la mención de los planes y UKPO GKPO. a ser ejecutado por auditorías internas y externas de la configuración, así como los procedimientos organizativos y tecnológicos apropiados, y se reflejan en las actas y D14 D15.

Implementación del software de plan de documento de certificación D16 fijo.

El ciclo de desarrollo de software se ha completado las pruebas confirman la idoneidad operativa del sistema funcional digital de a bordo (V9). Estas pruebas se llevan a cabo como parte del certificado oficial (certificación) que el sistema de este avión en las condiciones de funcionamiento establecidos funciona correctamente.

La documentación para la certificación de software. En los EE.UU., se produjo oficialmente 1987 Instituto método SEI (Software Engineering Institute), lo que permite determinar el nivel de madurez tecnológica de las empresas que desarrollan software y mejorar el proceso de desarrollo. Originalmente Capability Maturity

Model (CMM), y más tarde - Capability Maturity Model Integration (CMMI). De acuerdo con el modelo del más alto nivel ( "optimización") de madurez tecnológica - el quinto - responde proceso completamente automatizado para la producción sobre la base de un modelo matemático utilizando los métodos de optimización paramétrica y estructural y la organización se centra en la mejora de procesos. Uno de los signos de la inferior de la primera ( "primaria") nivel es organización dependiente de programadores individuales, y una de las condiciones para la transición de la segunda ( "repeticiones") nivel a un tercer ( "Definiciones") - procesos que documentan bajo control de servicio apropiado llevado por la persona responsable de la alta dirección de la organización.

Todas las fases del ciclo de vida del software tienen un principio y un fin a la documentación pueden existir para siempre. Por lo tanto, para formular los requisitos de documentación - que significa formular los requisitos para todo el proceso anterior de la creación de software. La documentación es el factor por el cual el material de software certificado. La documentación es también un elemento clave en la investigación analizó cuidadosamente los requisitos previos de desastres o emergencias.

Una forma muy importante y el contenido del documento, la inclusión de características cuantitativas y cualitativas del producto, la profundidad de su seguimiento y análisis, la presencia de la posibilidad de grabación y almacenamiento, el nivel de responsabilidad de las personas que firman el documento. El eslabón más débil de la documentación - visión completa de la declaración a sus demandas.

Una lista específica de los documentos requeridos para la certificación de software depende del software (en la criticidad del sistema) y se determina en el proceso de aprobación del plan de certificación del servicio de certificación. La siguiente muestra brevemente la esencia y los documentos ya mencionados.

  • D1 "Requisitos de software" - contiene una descripción de la transformación de los requisitos del sistema a los requisitos de software con la liberación de los requisitos de niveles altos y bajos y con especial atención a la seguridad y las posibles condiciones de fallo. Por definir características criterios de rendimiento y posibles limitaciones, como la memoria, tiempo-frecuencia, para la interacción. Se presta especial atención al aislamiento de los componentes de software.

  • D2 - "Normas de desarrollo de software" - lista plural. Por lo menos - se trata de una lista de normas formales, desarrollo de requerimientos, diseño, codificación, pruebas de software. Junto con las normas - algunos documentos.

  • Contenido Sus - métodos de creación, reglas de estructuración, restricciones en el proyecto (por ejemplo, la exclusión de la recursividad, objetos dinámicos, símbolos alternativos de datos), los límites a la complejidad (por ejemplo, la anidación de las llamadas, el uso de saltos) en el lenguaje y el compilador, el medio ambiente y las herramientas.

  • CLE - "Plan de certificación de software" se sirve a la aprobación de la autoridad de certificación del Estado, define los procedimientos, métodos de demostrar el cumplimiento de los requisitos del producto a él a un sistema para las Fuerzas Armadas y de la documentación requerida.

  • D4 "plan de desarrollo de software" - define el ciclo de vida de desarrollo de software, la interacción de los actores y el entorno de desarrollo.

  • D5 - "Plan de verificación del software" - define los pasos (la posición del proceso de desarrollo y criterios para la transición a los procedimientos de verificación), las técnicas, los procedimientos, el medio ambiente y las herramientas de verificación, incluyendo herramientas de software, instrucciones sobre el logro de los parámetros necesarios de calidad (seguridad) y las instrucciones de volver a analizar y prueba después de realizar cambios en el software, que garantizan la eliminación de los errores detectados.

  • D6 - "Plan de Gestión de la Configuración de Software" - establece las reglas para la identificación de software y equipo de unidades, la versión básica y la trazabilidad en las versiones derivadas de las normas de gestión del cambio, las reglas de orden y la contabilidad de estado de configuración, el archivo, el seguimiento y la protección del software de unidad de tratamiento de datos.

  • D7 - "El software de control de calidad del Plan" establece el alcance, responsabilidades y facultades de inspección y auditoría y otras actividades relacionadas con el proceso de obtención de garantías, incluidos los informes de problemas, su monitoreo y acciones correctivas.

  • D8 - "Descripción del software proyecto" - contiene una descripción detallada de la forma en que el software cumple con los requisitos de los requisitos de alto nivel, incluyendo algoritmos, estructuras de datos, y cómo los requisitos de software asignadas a tareas y procesos. Además, una descripción de la arquitectura de software, bibliotecas, que los flujos de entrada / salida de datos y controlar la asignación de recursos y las restricciones, procedimientos, programación, esquemas entre procesos relacionados y el intercambio entre aplicaciones, interrupciones, componentes de software, métodos para su aislamiento.

  • D9 "Código Fuente" - contiene el código fuente, las instrucciones de compilación para la generación de código, edición de datos y enlaces de descarga.

  • D10 - "Objeto código ejecutable" - contiene el código que es adecuado para la ejecución directa del procesador objetivo, calculadora, t E. Uno que se carga en el sistema de equipos de aviónica..

  • D11 - "software de configuración del producto" - define la configuración del producto entregado como una unidad. Se debe identificar el software como un todo, cada componente correspondiente a los documentos y medios de comunicación.

  • D12 - "Producto Medio Ambiente Software" - contiene una descripción del entorno del ciclo de vida del software, desde la etapa de especificar los requisitos y acabado fase de la cancelación de uso del producto. En el catálogo identificado por herramientas de desarrollo, verificación, software de seguimiento, proporciona datos sobre las calificaciones de herramientas.

  • D13 - "Los procedimientos y los resultados de la verificación" se puede dividir en dos o tres documentos, que deben ser descritos procedimientos para la revisión, análisis, pruebas en todas las etapas de desarrollo, ejemplos de aplicación y resultados de las pruebas de los procedimientos de los componentes del software identificados. Todos los problemas y las acciones correctivas deben ser descritos en detalle.

  • D14 - "Protocolos UKPO."

  • D15 - "Protocolos GKPO."

  • D16 - "La conclusión final sobre el software" - es el documento principal que sujeta la ejecución del "Plan de certificación de software" y la medida en que los "Requisitos de software". Debe contener una breve descripción del sistema y el software, las condiciones de certificación (acuerdos), las características, la identificación y el estado de la documentación del software para obtener una lista de software y una declaración de la medida en que los requisitos de software.

Blog y artículos

arriba