Términos y definiciones de sistemas automatizados. Requisitos para el soporte organizacional de los sistemas de control automatizados.

GOST 24.104-85 Sistemas de control automatizados. Requisitos generales (Sección 3 reemplazada por GOST 34.603-92) Sección 3 reemplazada por GOST 34.603-92 Por Decreto del Comité Estatal de Normas de la URSS del 20 de diciembre de 1985 No. 4632, se estableció la fecha de introducción

desde 01/01/1987

Esta norma se aplica a los sistemas de control automatizado (ACS) de todo tipo (excepto los nacionales) y establece requisitos generales para el ACS en su conjunto, las funciones del ACS, la formación del personal y los tipos de soporte del ACS, seguridad y ergonomía, tipos y procedimientos de prueba al poner en funcionamiento el ACS, integridad del sistema de control automatizado, garantías.

La norma no establece requisitos para los sistemas de control automatizados determinados por las características específicas de los objetos de control. Estos requisitos están formulados en las especificaciones técnicas para la creación o desarrollo de cada sistema de control automatizado o en otros documentos reglamentarios y técnicos del departamento del cliente del sistema de control automatizado.

Los requisitos adicionales para los sistemas de control automatizados de procesos tecnológicos, los sistemas de control automatizados para empresas, las asociaciones industriales y de producción científica y los sistemas de control automatizados específicos de la industria se establecen en los anexos obligatorios 1 a 3, respectivamente.

El Apéndice de referencia 4 proporciona explicaciones de algunos de los términos utilizados en la norma.

1. REQUISITOS PARA ACS

1.1. Requisitos para el sistema de control automatizado en general.

1.1.1. Un sistema de control automatizado de cualquier tipo debe cumplir con los requisitos de esta norma, los requisitos de las especificaciones técnicas para su creación o desarrollo (en adelante, las especificaciones técnicas del sistema de control automatizado), así como los requisitos de las normas reglamentarias y Documentos técnicos vigentes en el departamento del cliente del sistema de control automatizado.

1.1.2. La puesta en servicio de sistemas de control automatizados debería conducir a resultados técnicos, económicos, sociales o de otro tipo útiles, por ejemplo:

• reducir el número de personal directivo;
• mejorar la calidad del funcionamiento del objeto de control;
• mejorar la calidad de la gestión, etc.

1.1.3. El contenido específico de los requisitos establecidos en los párrafos. 1.1.2, 1.1.5-1.1.11, 1.2, 1.3, 1.4.2, 1.4.3, 1.4.6, 1.4.9, 1.5.2, 1.5.4, 1.5.6, 1.5.7, 1.6. 2, 1.6.6, 1.6.12, 1.7.2, 1.7.3 están instalados en las especificaciones técnicas del sistema de control automatizado.

1.1.4. El sistema de control automatizado debe garantizar el logro de los objetivos de su creación (desarrollo) establecidos en los términos de referencia del sistema de control automatizado.

1.1.5. El sistema de control automatizado debe garantizar la compatibilidad entre sus partes, así como con los sistemas automatizados (SA) interconectados con este sistema de control automatizado.

En los casos en que se crea un sistema de control automatizado o un conjunto de sistemas de control automatizado (AS) sobre la base de una red informática, se deben utilizar sistemas de protocolos de interacción multinivel para garantizar la compatibilidad entre los elementos de dicha red.

1.1.6. El sistema de control automatizado en su conjunto y todo tipo de soporte debe adaptarse a la modernización, desarrollo y ampliación dentro de los límites de los requisitos especificados en los términos de referencia del sistema de control automatizado.

1.1.7. La confiabilidad del sistema de control automatizado en su conjunto y de cada una de sus funciones automatizadas debe ser suficiente para lograr los objetivos establecidos de operación del sistema en determinadas condiciones de aplicación.

1.1.8. La adaptabilidad del sistema de control automatizado debe ser suficiente para lograr los objetivos establecidos de su funcionamiento en un rango determinado de cambios en las condiciones de aplicación.

1.1.9. El ACS debe prever el seguimiento del correcto desempeño de las funciones y diagnósticos automatizados, indicando la ubicación, tipo y causa de las violaciones del correcto funcionamiento del ACS.

1.1.10. Los ACS que tengan canales de medición deben tener la capacidad de controlar las características metrológicas de los canales de medición.

1.1.11. El sistema de control automatizado debe proporcionar medidas de protección contra acciones incorrectas del personal que conduzcan a una condición de emergencia de un objeto o sistema de control, contra cambios accidentales y destrucción de información y programas, así como contra intervenciones no autorizadas.

1.1.12. Cualquier información que ingrese al ACS se ingresa al sistema una vez utilizando un canal de entrada, a menos que esto conduzca al incumplimiento de los requisitos establecidos en las especificaciones técnicas del ACS (de confiabilidad, confiabilidad, etc.).

1.1.13. La información de salida del mismo contenido semántico debe generarse una vez en el sistema de control automatizado, independientemente del número de destinatarios.

1.1.14. La información contenida en las bases de datos del ACS deberá actualizarse de acuerdo con la frecuencia de su uso en el desempeño de las funciones del sistema.

1.1.15. El sistema de control automatizado debe estar protegido contra la fuga de información, si así se estipula en las especificaciones técnicas del sistema de control automatizado.

1.1.16. El nombre del SCA debe incluir el nombre del tipo de SCA y el objeto de control.

Por ejemplo:

• Sistema de control de procesos para calentar metal en un horno metódico;
• sistema de control automatizado organizativo y tecnológico en el taller No. 5;
• Sistema de control automático de la planta de la Hoz y el Martillo

1.2. Requisitos para las funciones ACS

1.2.1. El sistema de control automatizado, en la medida requerida, deberá realizar automáticamente:

• recopilación, procesamiento y análisis de información (señales, mensajes, documentos, etc.) sobre el estado del objeto de control;
• desarrollo de acciones de control (programas, planes, etc.);
• transmisión de acciones de control (señales, instrucciones, documentos) sobre la ejecución y su control;
• implementación y control de acciones de control;
• intercambio de información (documentos, mensajes, etc.) con sistemas automatizados interconectados.

1.2.2. La composición de las funciones automatizadas (tareas, conjuntos de tareas, en adelante funciones) del sistema de control automatizado debe garantizar la capacidad de controlar el objeto correspondiente de acuerdo con cualquiera de los objetivos establecidos en las especificaciones técnicas del sistema de control automatizado.

1.2.3. La composición de las funciones automatizadas del sistema de control automatizado y el grado de su automatización deben estar justificados técnica, económica y (o) socialmente, teniendo en cuenta la necesidad de liberar al personal de realizar acciones repetitivas y crear las condiciones para el uso de su creatividad. habilidades en el proceso de trabajo.

1.3. Requisitos para la preparación del personal del sistema de control automatizado.

1.3.1. Las calificaciones del personal de ACS deben garantizar el funcionamiento eficaz del sistema en todos los modos especificados.

1.3.2. El personal de ACS debe estar preparado para desempeñar sus funciones de acuerdo con las instrucciones de apoyo de la organización.

1.3.3. Cada persona que forme parte del personal del sistema automatizado de control deberá aplicar modelos de información adecuados y trabajar con los medios técnicos y la documentación que utilice y que determinen el procedimiento de sus actividades.

1.4. Requisitos para el soporte técnico de sistemas de control automatizados.

1.4.1. El conjunto de medios técnicos del sistema de control automatizado debe ser suficiente para realizar todas las funciones automatizadas del sistema de control automatizado.

1.4.2. El complejo de medios técnicos de los sistemas de control automatizados debería utilizar principalmente medios técnicos de producción en masa. Si es necesario, se permite el uso de medios técnicos de producción única.

1.4.3. Los sistemas de control automatizados replicados y sus partes deben construirse sobre la base de medios técnicos unificados.

1.4.4. Los medios técnicos del ACS deben colocarse cumpliendo con los requisitos contenidos en la documentación técnica, incluida la operativa, de los mismos, y de tal forma que sea conveniente utilizarlos durante el funcionamiento del ACS y realizar el mantenimiento.

1.4.5. La ubicación de los medios técnicos utilizados por el personal del sistema de control automatizado al realizar funciones automatizadas debe cumplir con requisitos ergonómicos: para equipos de producción de acuerdo con GOST 12.049-80, para medios de presentación de información visual de acuerdo con GOST 21829-76, incluso para tableros de uso colectivo. hecho de indicadores electroluminiscentes de síntesis de señales digitales según GOST 21837-76.

1.4.6. Los medios técnicos del sistema de control automatizado utilizados en la interacción del sistema de control automatizado con otros sistemas deben ser compatibles en las interfaces con los medios técnicos correspondientes de estos sistemas y los sistemas de comunicación utilizados.

1.4.7. El sistema de control automatizado deberá utilizar medios técnicos con una vida útil de al menos diez años. El uso de medios técnicos con una vida útil más corta está permitido sólo en casos justificados y de acuerdo con el cliente del sistema de control automatizado.

1.4.8. Cualquiera de los medios técnicos del sistema de control automatizado debe permitir su sustitución por un medio de finalidad funcional similar sin ningún cambio de diseño o ajuste en los medios técnicos restantes del sistema de control automático (excepto en los casos específicamente especificados en la documentación técnica del sistema de control automático). sistema de control automático).

1.4.9. Los medios técnicos ACS sólo podrán utilizarse en las condiciones especificadas en la documentación operativa de los mismos. En los casos en que sea necesario su uso en un entorno cuyos parámetros excedan los valores permitidos establecidos para estos medios técnicos, se deben tomar medidas para proteger los medios técnicos individuales del sistema de control automatizado de la influencia de factores externos.

1.4.10. El sistema de control automatizado debe utilizar tecnología informática que cumpla con los requisitos técnicos generales de acuerdo con GOST 22552-84.

1.4.11. El sistema de control automatizado deberá utilizar medios técnicos correspondientes a:

• para resistencia a factores de influencia externos: GOST 12997-76 para dispositivos industriales y equipos de automatización GSP, GOST 14254-80 para carcasas de productos de ingeniería eléctrica, GOST 17516-72 para productos de ingeniería eléctrica con respecto al impacto de factores ambientales mecánicos, GOST 21552-84 para tecnología de equipos informáticos;
• para parámetros de potencia: GOST 12997-76 para dispositivos industriales y equipos de automatización GSP, GOST 21552-84 para equipos informáticos;
• por categoría de rendimiento: GOST 12997-76 para dispositivos industriales y equipos de automatización GSP, GOST 21552-84 para equipos informáticos.

1.4.12. La protección de los medios técnicos del sistema de control automatizado contra la influencia de campos eléctricos y magnéticos externos, así como contra interferencias en los circuitos de suministro de energía, debe ser suficiente para que los medios técnicos cumplan eficazmente su propósito durante el funcionamiento del sistema de control automático.

1.4.13. En el ACS, de acuerdo con los requisitos estipulados por los "Estándares de interferencia industrial permisible de toda la Unión" 1-72 - 9-72 y GOST 23450-79, se deben tomar medidas para proteger el entorno externo de la interferencia de radio industrial emitida por los medios técnicos del ACS durante el funcionamiento, así como en el momento de encendido y apagado.

1.4.14. Requisitos ergonómicos generales para diagramas mnemotécnicos - según GOST 21480-76, para dispositivos de conteo para indicadores visuales - según GOST 22902-78, para uso colectivo tableros en indicadores electroluminiscentes de síntesis de caracteres digitales - según GOST 21837-76, para rayos catódicos tubos para mostrar información visual, según GOST 23144-78.

1.4.15. Requisitos ergonómicos generales para interruptores en paneles de control: interruptores giratorios, de acuerdo con GOST 22613-77, interruptores de teclado y pulsadores, de acuerdo con GOST 22614-77, tipo "interruptor de palanca", de acuerdo con GOST 22615-77.

1.4.16. Los requisitos ergonómicos generales para alarmas de mensaje primario audibles están de acuerdo con GOST 21786-76.

1.4.17. Requisitos ergonómicos generales que regulan la organización del lugar de trabajo, la disposición relativa de los dispositivos de visualización de información, controles y comunicaciones dentro del lugar de trabajo, de acuerdo con GOST 22269-76, incluidos los controles remotos, de acuerdo con GOST 23000-76.

1.4.18. Requisitos ergonómicos generales para sillas de operador de acuerdo con GOST 21889-76.

1.4.19. Los requisitos ergonómicos generales para la sala, las cabinas de los operadores y la disposición relativa de los asientos se ajustan a GOST 21958-76.

1.5. Requisitos del software ACS

1.5.1. El software del ACS debe ser suficiente para realizar todas las funciones del ACS, implementado mediante tecnología informática, y además tener los medios para organizar todos los procesos de procesamiento de datos requeridos, permitiendo la ejecución oportuna de todas las funciones automatizadas en todos los modos de operación regulados del ACS.

1.5.2. El software ACS debe tener las siguientes propiedades:

• suficiencia funcional (integridad);
• confiabilidad (incluida la capacidad de restauración, disponibilidad de herramientas de detección de errores);
• adaptabilidad;
• modificabilidad;
• modularidad de la construcción y
• facilidad de uso.

1.5.3. El software ACS debe construirse principalmente sobre la base de paquetes de software de aplicación existentes y otros programas tomados del gobierno, la industria y otros fondos de algoritmos y programas, permitir la carga y verificación de partes y permitir el reemplazo de algunos programas sin corregir otros.

1.5.4. El sistema de control automatizado debe utilizar principalmente sistemas de gestión de bases de datos (DBMS), registrados de la manera prescrita.

1.5.5. El software ACS debe construirse de tal manera que la ausencia de datos individuales no afecte el desempeño de las funciones ACS en cuya implementación no se utilizan estos datos.

1.5.6. El software ACS debe tener herramientas para diagnosticar el hardware ACS y monitorear la confiabilidad de la información de entrada.

1.5.7. El software ACS debe implementar medidas para proteger contra errores al ingresar y procesar información, asegurando la calidad especificada de desempeño de las funciones ACS.

1.5.8. El software general del sistema de control automatizado debe permitir la configuración de componentes de software especiales y el desarrollo posterior del software del sistema de control automatizado sin interrumpir el proceso de su funcionamiento. La parte del software ya generada y cargada debe protegerse de cambios accidentales.

1.5.9. Todos los programas de software especiales para un sistema de control automatizado específico deben ser compatibles tanto entre sí como con su software general.

1.5.10. La documentación del software operativo para el sistema de control automatizado debe cumplir con los estándares DEUC y contener toda la información necesaria para que el personal del sistema de control automatizado utilice el software, para su carga inicial y (o) generación, carga de información desde la base de información interna de la máquina, lanzamiento automatizado. programas de sistemas de control, y comprobar su funcionamiento mediante pruebas adecuadas.

1.5.11. Los productos de software recién desarrollados durante la creación de un sistema de control automatizado específico incluidos en su software deben estar registrados en el estado, la industria u otros fondos de algoritmos y programas (según corresponda).

1.6. Requisitos para el soporte de información de los sistemas de control automatizados.

1.6.1. El soporte de información del sistema de control automatizado debe ser suficiente para realizar todas las funciones automatizadas del sistema de control automatizado.

1.6.2. Para codificar información utilizada únicamente en un sistema de control automatizado determinado, se deben utilizar clasificadores aceptados por el cliente del sistema de control automatizado.

1.6.3. Para codificar la información de salida utilizada en un nivel superior en el ACS, se deben utilizar clasificadores de sistemas de control de nivel superior, excepto en casos especialmente especificados.

1.6.4. Los requisitos ergonómicos generales para la codificación de información se corresponden con GOST 21829-76.

1.6.5. En el sistema de control automatizado para la comunicación entre dispositivos de un conjunto de medios técnicos debe utilizarse lo siguiente:

• señales de entrada y salida:
  • eléctrico: corriente y voltaje según GOST 26.011-80, con cambios discretos en los parámetros según GOST 26.013-81, codificado según GOST 26.014-81,
  • hidráulico según GOST 26.012-80,
  • neumático según GOST 26.015-81;
• juegos de caracteres alfanuméricos según GOST 19767-74;
• Códigos de 8 bits según GOST 19768-74.

1.6.6. El soporte de información del sistema de control automatizado debe ser compatible con el soporte de información de los sistemas que interactúan con él, en términos de contenido, sistema de codificación, métodos de direccionamiento, formatos de datos y forma de presentación de la información recibida y emitida por el sistema de control automatizado.

1.6.7. Los formularios de documentos creados por el sistema de control automatizado deben cumplir con los requisitos de las normas USD o los documentos reglamentarios y técnicos del departamento del cliente del sistema de control automatizado.

1.6.8. Las formas de los documentos y cuadros de video ingresados, emitidos o ajustados a través de terminales ACS deben ser consistentes con las características técnicas relevantes de los terminales.

1.6.9. La totalidad de los conjuntos de información de los sistemas de control automatizados deben organizarse en forma de bases de datos en soporte informático.

1.6.10. La forma de presentación de la información de salida del sistema de control automatizado debe acordarse con el cliente (usuario) del sistema.

1.6.11. Los términos y abreviaturas utilizados en los documentos de salida del sistema de control automatizado deben ser generalmente aceptados en el área temática en cuestión y acordados con el cliente del sistema.

1.6.12. El sistema de control automatizado debe proporcionar las medidas necesarias para controlar y actualizar los datos en los conjuntos de información del sistema de control automatizado, restaurar los conjuntos después de la falla de cualquier medio técnico del sistema de control automatizado, así como controlar la identidad de la información de el mismo nombre en las bases de datos.

1.7. Requisitos para el soporte organizacional de los sistemas de control automatizados.

1.7.1. El soporte organizacional del sistema de control automatizado debe ser suficiente para el desempeño efectivo por parte del personal del sistema de control automatizado de las tareas que se le asignan en la implementación de responsabilidades automatizadas en la implementación de funciones automatizadas y no automatizadas relacionadas del sistema.

1.7.2. La estructura organizativa del sistema de control automatizado debe permitir la realización de todas las funciones del sistema de control automatizado, teniendo en cuenta su distribución entre los niveles directivos.

1.7.3. Los requisitos para la distribución de responsabilidades entre el personal involucrado en la operación del sistema de control automatizado en tiempo real se determinan teniendo en cuenta los requisitos de la cláusula 11 del Apéndice 1 obligatorio.

1.7.4. Las instrucciones para el soporte organizacional del sistema de control automatizado deben determinar las acciones del personal del sistema de control automatizado necesarias para realizar cada función automatizada en todos los modos de operación del sistema de control automatizado, teniendo en cuenta los requisitos especificados para la precisión y velocidad de implementación. por el personal del sistema de control automatizado de sus funciones funcionales, y también contienen instrucciones específicas sobre acciones en caso de situaciones de emergencia o violación de las condiciones normales de funcionamiento del sistema de control automatizado. Los requisitos para el contenido de las instrucciones se ajustan a GOST 24.209-80.

1.7.5. Para cada función automatizada que se realiza en interacción de este ACS con otros sistemas, las instrucciones al personal del ACS y estos sistemas deben estar interconectadas para todos los modos de realizar esta función y contener instrucciones sobre las acciones del personal en caso de fallas de medios técnicos del ACS.

1.8. Requisitos para el soporte lingüístico de los sistemas de control automatizados.

1.8.1. El soporte lingüístico del sistema de control automatizado debe ser suficiente para la comunicación entre varias categorías de usuarios en una forma conveniente para ellos con las herramientas de automatización del sistema de control automatizado y para llevar a cabo procedimientos de conversión y representación mecánica de la información procesada en el sistema de control automatizado.

1.8.2. El soporte lingüístico del sistema de control automatizado deberá incluir:

• se proporcionan herramientas de lenguaje para describir cualquier información utilizada en el sistema de control automatizado;
• los medios lingüísticos utilizados están unificados;
• se han estandarizado las descripciones de elementos similares de información y el registro de estructuras sintácticas;
• Se garantiza la comodidad, la claridad y la estabilidad de la comunicación entre los usuarios y los sistemas de control automatizados;
• Se proporcionan medios para corregir los errores que se produzcan cuando los usuarios se comunican con los medios técnicos del sistema automatizado de control.

1.8.3. El soporte lingüístico del sistema de control automatizado debe reflejarse en la documentación (instrucciones, descripciones) del soporte organizativo del sistema de control automatizado en forma de reglas para la comunicación entre los usuarios y los medios técnicos del sistema de control automatizado en todos los modos de sistema. operación.

1.9. Requisitos para el soporte legal de los sistemas de control automatizados.

El soporte legal para los sistemas de control automatizados debe incluir un conjunto de normas legales:

• determinar la validez legal de la información sobre los soportes de datos y los documentos utilizados en el funcionamiento del sistema de control automatizado y creados por el sistema;
• que regula las relaciones jurídicas entre las personas que forman parte del personal del ACS (derechos, deberes y responsabilidades), así como entre el personal del ACS y el personal de los sistemas que interactúan con el ACS.

Nota. Las reglas y regulaciones que surgen de la validez legal de la información sobre los soportes de datos y las regulaciones legales deben incluirse en las instrucciones y regulaciones de soporte organizacional para los servicios ICS relevantes.

1.10. Requisitos para la documentación operativa de sistemas de control automatizados.

1.10.1. La documentación operativa del ACS debe ser suficiente para la puesta en funcionamiento del ACS y para su eficaz funcionamiento.

1.10.2. La documentación operativa del sistema de control automatizado debe:

• contener la información necesaria para el desarrollo rápido y de alta calidad y el funcionamiento adecuado de los sistemas de control automatizados;
• contener instrucciones sobre las actividades del personal de ACS en situaciones de emergencia o en caso de violación de las condiciones normales de funcionamiento de ACS;
• no contener disposiciones que estén sujetas a interpretación ambigua.

2. REQUISITOS DE SEGURIDAD

2.1. Las acciones incorrectas del personal de ACS no deberían provocar una emergencia.

2.2. Los requisitos de seguridad para productos eléctricos utilizados en sistemas de control automatizados están de acuerdo con GOST 12.2.007.0-75.

2.3. Los requisitos de seguridad para los equipos informáticos utilizados en los sistemas de control automatizados se ajustan a GOST 25861-83.

2.4. Todos los elementos externos de los medios técnicos del sistema de control automático que estén energizados deben estar protegidos contra contactos accidentales, y los propios medios técnicos deben estar conectados a tierra o de forma protectora de acuerdo con GOST 12.1.030-81 y las "Reglas para dispositivos de suministro de energía". .

2.5. Los equipos técnicos ACS ubicados en instalaciones con riesgo de explosión e incendio deben cumplir con los requisitos de las "Reglas de suministro de energía".

2.6. Los medios técnicos del ACS deberán instalarse de forma que se garantice su funcionamiento y mantenimiento seguros.

2.7. Los requisitos de seguridad deben establecerse en una sección especial de las descripciones de trabajo y (o) instrucciones de funcionamiento de los sistemas de control automatizados y deben tener enlaces a las instrucciones de funcionamiento de los equipos técnicos.

2.8. Los requisitos ergonómicos generales para los lugares de trabajo del personal de los sistemas de control automatizados están de acuerdo con GOST 22269-76.

2.9. Las condiciones de vida cómodas para el personal del sistema de control automatizado deben cumplir con los estándares sanitarios vigentes, las condiciones de vida máximas permitidas (de acuerdo con GOST 12.1.005-76, los niveles permitidos de influencia de factores de producción peligrosos y dañinos) de acuerdo con GOST 12.0.003-74. .

2.10. Los requisitos ergonómicos generales para el microclima de las instalaciones de trabajo del personal del sistema de control automatizado se corresponden con GOST 12.1.005-76.

2.11. Los niveles de ruido y potencia acústica en las ubicaciones del personal del sistema de control automatizado no deben exceder los valores establecidos por GOST 12.1.003-83 y las normas sanitarias, mientras que los niveles de ruido y potencia acústica creados por todas las fuentes, incluidos los medios acústicos de La transmisión de datos debe tenerse en cuenta.

2.12. Los niveles de iluminación de los lugares de trabajo del personal de los sistemas de control automatizados deben corresponder a la naturaleza y las condiciones de trabajo. Se debe proporcionar protección contra el deslumbramiento y reducción del deslumbramiento.

2.13. Los requisitos ergonómicos generales para la vibración de equipos en los lugares de trabajo del personal de los sistemas de control automatizados se corresponden con GOST 12.1.012-78.

2.14. Colores de señales y señales de seguridad según GOST 12.4.026-76.

3. TIPOS Y PROCEDIMIENTO DE PRUEBAS AL PONER EN FUNCIONAMIENTO EL ACS

Este apartado se aplica a todos los sistemas de control automatizados, excepto a los creados por orden del Ministerio de Defensa.

3.1. Un sistema de control automatizado o una función entregada por separado de un sistema de control automatizado (en adelante, el sistema de control automatizado), al ponerlo en funcionamiento, debe someterse a pruebas preliminares y de aceptación, así como a las pruebas previstas por los documentos reglamentarios y técnicos. vigente en el departamento del cliente del sistema de control automatizado.

3.2. La prueba de aceptación del sistema de control automatizado debe ir precedida de su funcionamiento de prueba en la instalación de control.

3.3. Las pruebas de ACS se llevan a cabo de acuerdo con el documento "Programa de pruebas", que prepara el desarrollador de ACS. Los requisitos para el contenido del programa de prueba se corresponden con GOST 24.208-80.

3.4. Las pruebas ACS pueden realizarse en una o varias etapas.

Basándose en los resultados de las pruebas, el ACS elabora un "Informe de prueba". Los requisitos para el contenido del informe de prueba se corresponden con GOST 24.208-80.

Al probar un ACS paso a paso, el "Informe de prueba" basado en los resultados de la etapa anterior debe contener una conclusión sobre la posibilidad de enviar el ACS a la siguiente etapa de prueba.

3.5. Pruebas preliminares del sistema de control automatizado.

3.5.1. Se llevan a cabo pruebas preliminares del sistema de control automatizado para determinar su desempeño y resolver la cuestión de la posibilidad de aceptar el sistema de control automático para operación de prueba.

3.5.2. El "programa de prueba" para las pruebas preliminares del ACS lo aprueba el cliente del ACS.

3.5.3. Las pruebas preliminares del ACS las organiza el cliente y las llevan a cabo conjuntamente el desarrollador del ACS y el cliente.

3.5.4. La comisión para la realización de pruebas preliminares del sistema de control automatizado se forma por orden del cliente. Se nombra presidente de la comisión a un representante del cliente del sistema de control automatizado.

3.5.6. El "Informe de prueba", elaborado a partir de los resultados de las pruebas preliminares del ACS, proporciona una conclusión sobre la posibilidad de aceptar el ACS para su operación de prueba, así como una lista de las modificaciones necesarias y los plazos recomendados para su implementación.

3.6. Operación de prueba de sistemas de control automatizados.

3.6.1. Los resultados de la aceptación del ACS para la operación de prueba están documentados en el "Certificado de Aceptación para la Operación de Prueba", elaborado sobre la base del "Informe de prueba" por la comisión que realizó las pruebas preliminares del ACS. Los requisitos para el contenido de la ley están de acuerdo con GOST 24.208-80.

3.6.2. La duración de la operación de prueba del sistema de control automatizado está determinada por el tiempo requerido para verificar el correcto funcionamiento del sistema de control automatizado al realizar cada función automatizada y la preparación del personal del sistema de control automatizado para participar en el desempeño de todas las funciones automatizadas de el sistema de control automatizado.

3.6.3. La duración mínima de la operación de prueba del sistema de control automatizado (excepto el sistema de control automático) antes de las pruebas de aceptación se determina para cada función automatizada del sistema de control automatizado que se presente; debe corresponder a los valores indicados en el mesa. Si la duración total de las interrupciones de la continuidad de una función automatizada excede el valor especificado en la tabla, la operación de prueba debe continuar hasta que se obtengan resultados consistentes con la tabla o hasta que se tome la decisión de terminarla.

Se permite, previo acuerdo con el cliente, enviar el ACS para pruebas de aceptación sin operación de prueba de aquellas funciones automatizadas cuya frecuencia de solución sea inferior a una vez al mes, siempre que no solo dichas funciones estén automatizadas en el ACS.

Frecuencia de ejecución de funciones automatizadas.	Duración mínima de la operación de prueba del sistema de control automatizado antes de las pruebas de aceptación.	Duración total permitida de las interrupciones en la continuidad de la ejecución de una función del sistema de control automatizado.
Continuamente	1 mes	No más de 3 días
Una vez al día o más a menudo	Mismo	No más del 10% del número previsto de soluciones.
Menos de una vez al día a una vez al mes.	3 meses	Mismo
Menos de una vez al mes a una vez cada seis meses.	Periodo entre dos decisiones consecutivas	No se permiten interrupciones en la continuidad del desempeño de la función.
Una vez al año o menos	El período de tiempo requerido para probar la tecnología adoptada para recopilar y procesar información durante una ejecución única de la función ACS.	Mismo

Notas:

1. Se considera violación de la continuidad de la ejecución de una función automatizada de un sistema de control automatizado su no realización en el momento especificado en la documentación técnica del sistema de control automatizado, a menos que sea causado por una violación de las condiciones de funcionamiento del sistema de control automatizado o del objeto de control.

2. Si la duración real de la operación de prueba del sistema de control automatizado fue mayor que el tiempo indicado en la segunda columna de la tabla, entonces la duración total de la interrupción de la continuidad de la ejecución para cada función automatizada se determina por el período de tiempo. indicado en la tabla e inmediatamente anterior a las pruebas de aceptación.

3.6.4. Durante la operación de prueba del ACS, se lleva un registro de trabajo en el que se registra información: sobre la duración del funcionamiento del ACS, sobre los resultados del seguimiento del correcto funcionamiento del ACS, sobre fallas, mal funcionamiento, situaciones de emergencia, sobre cambios. en los parámetros del objeto de control y ajustes continuos a la documentación técnica.

3.6.5. Sobre la base de los resultados de la operación de prueba, se elabora un certificado de finalización del trabajo de verificación del sistema de control automatizado en el modo de operación de prueba. Los requisitos para el contenido de la ley están de acuerdo con GOST 24.208-80.

3.7. Pruebas de aceptación de ACS

3.7.1. Se realizan pruebas de aceptación del ACS para determinar su cumplimiento de las especificaciones técnicas del ACS, los requisitos de esta norma y para determinar la posibilidad de poner el ACS en funcionamiento.

3.7.2. Dependiendo de la importancia del objeto de control y del sistema de control automatizado, las pruebas de aceptación pueden ser:

• gobierno;
• interdepartamental;
• departamental

y deberá ser realizado por los comités de aceptación correspondientes. El comité de aceptación se forma por orden del ministerio (departamento) del cliente del sistema de control automatizado. El nivel del comité de aceptación deberá estar establecido en las especificaciones técnicas del sistema de control automatizado.

3.7.3. Se nombra a un representante del cliente del sistema de control automatizado como presidente del comité de aceptación. El comité de aceptación debe incluir representantes del desarrollador de ACS.

3.7.4. El trabajo del comité de aceptación no incluye la aceptación de edificios, estructuras y equipos auxiliares, cuya creación se llevó a cabo en relación con la creación de un sistema de control automatizado. La comisión verifica únicamente la disponibilidad de certificados de aceptación para la operación y el cumplimiento de los requisitos contenidos en los encargos de diseño en partes adyacentes del proyecto de la instalación, emitidos durante el diseño del sistema de control automatizado.

3.7.5. El cliente y el desarrollador presentan la siguiente documentación al comité de aceptación:

• términos de referencia para la creación de un sistema de control automatizado;
• borrador del programa de pruebas de aceptación;
• Informe de prueba preliminar del ACS;
• certificado de aceptación del sistema de control automatizado para operación de prueba;
• acto(s) al finalizar el trabajo de verificación del sistema de control automatizado en modo de operación de prueba;
• documentación técnica del sistema de control automatizado (por decisión del comité de aceptación).

3.7.6. Antes de someterse a pruebas de aceptación, los sistemas de control automatizados con canales de medición están sujetos a una certificación metrológica de acuerdo con las normas vigentes.

3.7.7. Antes de presentar el ACS para las pruebas de aceptación, se debe finalizar el sistema y su documentación técnica con base en los comentarios del protocolo de prueba preliminar y el certificado de finalización del trabajo de verificación del ACS en modo de operación de prueba.

Se permite, por decisión del comité de aceptación, finalizar la documentación técnica del sistema de control automatizado una vez puesto en funcionamiento. Los plazos para finalizar la documentación técnica del sistema de control automatizado se indican en el informe de prueba de aceptación del sistema.

3.7.8. Las pruebas de aceptación del sistema de control automatizado deben realizarse en una instalación de control en funcionamiento.

3.7.9. El "programa de pruebas" para las pruebas de aceptación del sistema de control automatizado debe ser aprobado mediante decisiones del comité de aceptación. Es obligatoria la coordinación del programa de pruebas de aceptación con el cliente del sistema de control automatizado.

3.7.10. Con base en los resultados de las pruebas de aceptación, la comisión elabora un informe de prueba y un acto sobre la puesta en funcionamiento del ACS (o una conclusión sobre la no aceptación del ACS con una lista de las modificaciones necesarias y los plazos recomendados para su implementación). Requisitos para el contenido del protocolo y actuar de acuerdo con GOST 24.208-80. Los requisitos para el contenido de la conclusión sobre la no aceptación del sistema de control automatizado son similares a los requisitos para el contenido de la ley sobre la puesta en vigor del sistema de control automatizado.

3.7.11. En el caso de pruebas de aceptación por etapas, el acto de puesta en funcionamiento del sistema de control automatizado se redacta sobre la base de los actos de puesta en funcionamiento de partes individuales del sistema y (o) "Informes de prueba" de todos etapas de las pruebas de aceptación del sistema de control automatizado.

3.7.12. Se considera fecha de puesta en servicio del sistema de control automatizado la fecha de firma del acta de puesta en servicio por parte del comité de aceptación.

3.7.13. La ley sobre la puesta en funcionamiento del sistema de control automatizado es aprobada por el ministerio (departamento) del cliente.

4. INTEGRIDAD DEL ACS PUESTA EN FUNCIONAMIENTO

4.1. El ACS debe incluir:

• Medios técnicos ACS en forma de un complejo de medios técnicos ACS preparados para su funcionamiento;
• repuestos y dispositivos (SPTA), instrumentos y dispositivos para probar la operatividad, configurar equipos técnicos y monitorear las características metrológicas de los canales de medición del sistema de control automatizado en la medida prevista por la documentación de diseño personalizado acordada con el cliente del sistema automático. sistema de control y servicio de metrología del usuario en cuanto a equipos de prueba;
• documentación operativa de acuerdo con GOST 2.601-68 para cada uno de los productos incluidos en el CTS ACS;
• al menos dos copias de los programas en soportes de datos y la documentación operativa sobre ellos de acuerdo con GOST 19.101-77, teniendo en cuenta las restricciones y adiciones de acuerdo con GOST 24.101-80 y GOST 24.207-80;
• un formulario para el software ACS en su conjunto o para el software de una función ACS puesta en funcionamiento por separado y formularios para productos de software (según GOST 19.004-80), cada uno en una copia. Requisitos del formulario: según GOST 19.501-78;
• dos copias de la documentación operativa del sistema de control automatizado de acuerdo con GOST 24.101-80, incluida la documentación necesaria para el soporte de información del sistema de control automatizado (el formulario del sistema de control automatizado en una copia).

Mediante acuerdo entre el desarrollador de ACS y el cliente de ACS, se puede ampliar la integridad del ACS.

4.2. El personal de ACS debe contar con personal que cumpla con los requisitos de la cláusula 1.3.

4.3. Para completar el sistema de control automatizado creado, se pueden utilizar los siguientes, suministrados como productos técnicos y de producción:

• complejos (complejos) de hardware y software con documentación operativa para ellos de acuerdo con GOST 2.601-68;
• productos de software con documentación operativa para ellos de acuerdo con GOST 19.101-77;
• Equipo técnico con documentación operativa para ellos de acuerdo con GOST 2.601-68.

4.4. El procedimiento de desarrollo, puesta en producción y prueba de los componentes suministrados utilizados en el sistema de control automatizado debe cumplir con las normas estatales para el sistema de desarrollo y puesta en producción de productos.

Antes de su puesta en producción, los prototipos de componentes se someten a pruebas de aceptación (estatales, interdepartamentales, departamentales).

5. GARANTÍA

5.1. El desarrollador del sistema de control automatizado garantiza el cumplimiento del sistema de control automatizado con los requisitos de esta norma y las especificaciones técnicas del sistema de control automático, sujeto al cumplimiento por parte del usuario de las condiciones y reglas de operación.

5.2. El cumplimiento de los sistemas de hardware, software y equipos de automatización utilizados en sistemas de control automatizados y suministrados como productos técnicos y de producción con los requisitos de las normas y especificaciones para los mismos está garantizado por los fabricantes de este tipo de productos, sujeto al cumplimiento por parte del usuario de las condiciones operativas. condiciones y reglas.

5.3. El período de garantía del ACS se calcula a partir de la fecha de puesta en funcionamiento del ACS.

5.4. El periodo de garantía del ACS deberá estar establecido en las especificaciones técnicas del ACS y no podrá ser inferior a 18 meses.

ANEXO 1
Obligatorio

REQUISITOS ADICIONALES PARA SISTEMAS AUTOMATIZADOS DE CONTROL DE PROCESOS (APCS)

1. Los sistemas de control de procesos en la industria y en el ámbito no industrial deben gestionar el objeto tecnológico en su conjunto y suministrar a los sistemas interconectados información tecnológica, técnica y económica fiable sobre el funcionamiento del objeto de control tecnológico (TOU).

2. El sistema automatizado de control de procesos deberá desarrollar e implementar acciones de control sobre el sistema de control que sean racionales en cuanto a objetivos y criterios de control en tiempo real del proceso tecnológico en el objeto de control.

3. El sistema automatizado de control de procesos deberá realizar funciones de control, información y auxiliares.

4. El sistema de control de procesos debe ser compatible con todos los sistemas automatizados (AS) interconectados con él, especificados en los términos de referencia del sistema de control de procesos, incluidos los sistemas incluidos con este sistema de control de procesos como parte de una producción automatizada flexible, por ejemplo, Tecnologías CAD, sistemas automatizados de almacén y transporte, AS para la preparación tecnológica de la producción.

5. Las acciones de control en el sistema automatizado de control de procesos deberán ser generadas automáticamente o generadas por su personal operativo utilizando un conjunto de herramientas de automatización incluidas en el sistema.

6. El sistema automatizado de control de procesos deberá garantizar el control de la instalación en condiciones normales, transitorias y previas a la emergencia de su funcionamiento, así como la protección o parada de la instalación en caso de amenaza de accidente.

7. El sistema automatizado de control de procesos deberá desempeñar la función de controlar la ejecución de las acciones de control sobre los equipos técnicos y señalar cuándo los órganos ejecutivos alcanzan sus posiciones máximas permitidas.

8. Al implementar la función de desviación automática de emergencia de equipos en el sistema de control de procesos, se debe proporcionar una alarma al personal operativo mediante señales luminosas y, si es necesario, sonoras con registro automático del tiempo de parada.

9. Como principal medio técnico de los sistemas automatizados de control de procesos, se deben considerar los productos del Sistema Estatal de Instrumentos Industriales y Equipos de Automatización (GSP), otros productos que cumplan con los requisitos de las normas ESSP y equipos informáticos que cumplan con GOST 21552-84. usado.

10. Los medios técnicos de los sistemas automatizados de control de procesos ubicados en equipos de proceso deben cumplir con los requisitos para sus condiciones de operación.

11. Las responsabilidades entre operadores deberían distribuirse teniendo en cuenta:

• participación del personal en el desempeño de funciones manuales del sistema y su interacción con otros sistemas;
• el nivel permisible de carga psicofisiológica y emocional de los operadores establecido por los documentos normativos y técnicos de la industria asociados con el desempeño de las funciones asignadas a cada uno de ellos y su responsabilidad por los resultados finales e intermedios del trabajo, así como el nivel requerido de su actividad. en el proceso de trabajo.

12. Cada persona incluida en la plantilla deberá tener:

• conocimiento, cuyo volumen y profundidad le permite realizar acciones (interacciones) incluidas en las correspondientes funciones automatizadas y no automatizadas interconectadas del sistema automatizado de control de procesos, así como tomar las decisiones correctas en situaciones de emergencia u otras violaciones del funcionamiento normal. ;
• Habilidades desarrolladas que permiten realizar todas las acciones e interacciones con precisión y velocidad especificadas.

13. El software del sistema automatizado de control de procesos debe proporcionar, y el soporte organizacional debe reflejar, herramientas lingüísticas para la comunicación entre el personal operativo y el sistema automatizado de control de procesos, convenientes y accesibles para personas que no tengan calificaciones de programador.

14. Los códigos y símbolos utilizados en el sistema de control de procesos deben acercarse a los términos y conceptos utilizados por el personal tecnológico del objeto de control y no deben causar dificultades en su percepción.

15. Los canales de medición del sistema automatizado de control de procesos deberán tener características metrológicas que aseguren el desempeño de sus funciones de información con los indicadores especificados en las especificaciones técnicas del sistema automatizado de control de procesos.

16. Requisitos para probar sistemas automatizados de control de procesos.

16.1. Las pruebas preliminares del sistema automatizado de control de procesos se llevan a cabo en un equipo técnico existente.

16.2. Las pruebas preliminares de las funciones del sistema automatizado de control de procesos necesarias para la puesta en marcha y el rodaje de los equipos de proceso se pueden realizar in situ mediante simuladores.

16.3. La determinación de los valores reales de los indicadores de eficiencia y confiabilidad técnica y económica del sistema automatizado de control de procesos se lleva a cabo después de su puesta en servicio. El tiempo de funcionamiento del sistema automatizado de control de procesos, necesario para determinar los valores reales de sus indicadores, se calcula de acuerdo con los métodos apropiados aprobados en la forma prescrita.

APÉNDICE 2
Obligatorio

REQUISITOS ADICIONALES PARA ACS POR EMPRESAS, ASOCIACIONES DE PRODUCCIÓN Y DE INVESTIGACIÓN Y PRODUCCIÓN

1. El sistema de control automatizado deberá aumentar la eficiencia de la producción y las actividades económicas de las empresas, asociaciones productivas o científicas y productivas (en adelante, empresas).

2. El sistema de control automatizado (ACS) empresarial debe garantizar la recopilación y el procesamiento automatizados de información con el uso generalizado de métodos de optimización para las principales tareas y subsistemas de control a nivel general de planta y taller, incluido, si es necesario, en tiempo real el teleprocesamiento. y modo de diálogo.

3. El sistema de control automatizado deberá implementarse como un conjunto de subsistemas que funcionen conjuntamente, cuya interacción debe producirse a través de una base de datos común (única o distribuida).

4. El apoyo organizacional a los sistemas de control automatizados debe proporcionar la mejora de los métodos de gestión y la estructura del sistema de gestión empresarial durante la creación y desarrollo de sistemas de control automatizados.

APÉNDICE 3
Obligatorio

REQUISITOS ADICIONALES PARA SISTEMAS DE CONTROL AUTOMATIZADOS DE LA INDUSTRIA (OACS)

1. OASU debe garantizar:

• mejorar las características del objeto de control (aumentar la productividad laboral en la industria, mejorar la calidad del producto, entrega oportuna de los productos, reducir el costo de los productos fabricados);
• mejora de los procesos de procesamiento de información (reduciendo el costo de procesamiento de información, aumentando la confiabilidad de los iniciales, aumentando la precisión y eficiencia de los cálculos);
• mejorar la organización de las funciones de gestión (en particular, la distribución racional del trabajo entre departamentos del aparato de gestión, centros informáticos y organizaciones y empresas de investigación).

2. La OASU deberá automatizar las funciones de gestión de la industria, por ejemplo:

• previsión y planificación de la producción y los recursos de la industria;
• gestión del desarrollo científico y técnico de la industria y preparación técnica de la producción industrial;
• gestión de la fuerza laboral de la industria;
• gestión de recursos materiales de la industria;
• gestión de la construcción de capital en la industria;
• gestión de recursos financieros de la industria;
• gestión, incluida la gestión operativa, de la producción principal a nivel industrial, etc.

3. La OACS debería implementarse como un conjunto de subsistemas que funcionen conjuntamente, cuya interacción debería realizarse a través de bases de datos comunes.

4. OASU debe incluir un sistema de recopilación de datos basado en los centros de computación de OASU, organizaciones y empresas de la industria, asegurando la distribución racional de información en bases de datos para resolver problemas de interacción y la transferencia de información entre sistemas a través de canales de comunicación y en medios informáticos.

5. La OACS debe proporcionar un modo interactivo de trabajar con las bases de datos del sistema.

6. La creación de la OASU debería conducir a la mejora de los métodos y la estructura de gestión de la industria.

7. La duración de la operación de prueba de las partes del OACS debe garantizar la realización única de todos los cálculos necesarios para realizar las funciones automatizadas de la parte introducida del OACS, y no debe exceder los 3 meses.

La duración específica de la operación de prueba de OASU se establece mediante acuerdo entre el desarrollador y el cliente.

APÉNDICE 4
Información

EXPLICACIÓN DE ALGUNOS TÉRMINOS UTILIZADOS EN ESTA NORMA

Complejo de equipos de automatización (CAS)- un conjunto suministrado de conjuntos de hardware y software (productos) mutuamente acordados, desarrollados y fabricados como productos para fines industriales y técnicos. La KSA también puede incluir otros productos y (o) documentos incluidos en la información, organización u otros tipos de soporte para sistemas automatizados.

Ampliación de los sistemas de control automatizados.- un conjunto de medidas tomadas en el sistema de control automatizado al ampliar su objeto de control sin cambiar la composición de las funciones del sistema de control automatizado.

Fotograma de vídeo (en ACS)- imagen en la pantalla de un documento de tubo de rayos catódicos de un dibujo o texto de mensaje utilizado en el sistema de control automatizado.

Canal de medición ACS- un conjunto funcionalmente integrado de herramientas técnicas y (si es necesario) de software diseñadas para implementar una función de medición simple del sistema de control automatizado.

Pruebas preliminares del sistema de control automatizado.- pruebas de control realizadas para determinar la posibilidad de aceptar el sistema de control automatizado para su operación de prueba.

Pruebas de aceptación de ACS- pruebas de control del sistema de control automatizado, realizadas para determinar su cumplimiento de las especificaciones técnicas para la creación del sistema de control automatizado, los requisitos de las normas y para determinar la posibilidad de poner en funcionamiento el sistema de control automatizado.

pruebas estatales- pruebas de aceptación de sistemas de control automatizados realizadas por la comisión estatal.

Pruebas interdepartamentales- pruebas de aceptación de sistemas de control automatizados realizadas por una comisión de representantes de varios ministerios y (o) departamentos interesados.

Pruebas departamentales- pruebas de aceptación de sistemas de control automatizados realizadas por una comisión de representantes del ministerio o departamento interesado.

Editor A.I. Lomina
Editor técnico n.p. Zamolodchikova
Corrector de pruebas E.I. Evteeva
Entregado al set el 16/01/86. Firmado para publicación el 08/04/86. Condicional horno l. 1.5. Condicional cr.-ott. 1.5 Educación académica. l. 1.5.
Circulación 40.000 Precio 10 kopeks.
Pedido "Badge of Honor" Editorial de normas, 123810, Moscú, GSP, Novopresnensky lane, 3
Tipo. "Impresora de Moscú", Moscú, Lyalin Lane, 6. Orden 1772

Hoy hablaremos sobre estándares nacionales para la documentación de diseño. Cómo funcionan estas normas en la práctica, por qué son malas y por qué son buenas. A la hora de desarrollar documentación para gobiernos y clientes privados serios, normalmente no tenemos otra opción: el cumplimiento de las normas está incluido entre los requisitos para documentar las especificaciones técnicas. En la práctica, me he encontrado con varios ejemplos de malentendidos sobre la estructura de las normas, qué debería estar en los documentos y por qué son necesarios. Como resultado, las plumas de escritores técnicos, analistas y especialistas a veces producen tales joyas que no está claro en qué estado de conciencia fueron escritas. Pero, de hecho, todo es bastante sencillo. Una búsqueda en Habr no arrojó ningún enlace a material más o menos completo sobre este tema, por lo que propongo llenar este molesto vacío.

¿Qué son los estándares de documentación?

En la serie 34 en cuestión, solo existen 3 estándares de documentación principales:

El estándar más querido y popular para el desarrollo de especificaciones técnicas. Lo único que no debe olvidar es que está estrechamente relacionado con otros estándares de la serie, y si ha recibido especificaciones técnicas elaboradas de acuerdo con este estándar, es muy recomendable adherirse a otros estándares, incluso si no existen requisitos directos. para esto. Al menos en términos de ideología general (sobre la cual a continuación)

Este es un documento básico que proporciona una lista completa de la documentación GOST 34, recomendaciones para codificar documentos, a qué etapas del proyecto pertenecen los documentos (las etapas se describen en GOST 34.601-90), así como cómo se pueden combinar entre sí. .

De hecho, este estándar es una gran tabla con comentarios. Se puede poner en Excel para facilitar su uso.

Un estándar voluminoso que describe el contenido de los documentos del proyecto con distintos grados de detalle. Como índice se utiliza el GOST 34.201-89 mencionado anteriormente.

Existen muchas dudas e interpretaciones de sus disposiciones respecto a la norma RD 50-34.698-90, que por su vaguedad, muchas veces son entendidas de manera diferente por el cliente y el contratista, o incluso miembros del equipo del proyecto. Pero lamentablemente no tenemos nada más concreto.

Consideremos ahora los pros y los contras de las normas, empezando tradicionalmente por los contras.

Desventajas de los estándares

La principal desventaja es obvia para todos: los estándares son antiguos. Contienen una idea obsoleta de la arquitectura de un sistema automatizado. Por ejemplo:

• aplicaciones de dos niveles, que consisten en un programa cliente y un servidor DBMS (no aplicaciones de tres o más “niveles”, ni Weblogic ni JBoss)
• la estructura de las tablas de la base de datos, descrita, dará una idea del modelo lógico de datos (el hecho de que pudiera haber algún tipo de Hibernación entre la aplicación y la base de datos parecía un mal exceso entonces)
• la interfaz de usuario es de ventana única (¿hay algo más? ¿Qué es un “navegador”?)
• Hay pocos informes en el sistema, todos están en papel y están impresos en una impresora matricial.
• El programa que se desarrolla está enfocado a resolver el “problema del procesamiento de la información”, que tiene entradas y salidas claras y es altamente especializado. El procesamiento de la información se basa en un “algoritmo”. A veces existen varios "algoritmos". (La programación orientada a objetos estaba entonces dando sus primeros pasos y no se consideró seriamente).
• el administrador de la base de datos comprende qué información hay en las tablas y participa activamente en la edición de los directorios del sistema (¿existe realmente un servidor DBMS para 50 aplicaciones diferentes?)

En consecuencia, el estándar tiene artefactos como los siguientes:

5.8. Dibujo del formulario del documento (fotograma de vídeo)
El documento debe contener una imagen de la forma del documento o un cuadro de video de acuerdo con los requisitos de los estándares estatales del sistema unificado de documentación R 50-77 y las explicaciones necesarias.

La cuestión del documento es que las empresas soviéticas utilizaban las llamadas "Áreas de impresión", donde había impresoras matriciales de alta velocidad, cuyos controladores a menudo eran escritos por los propios ingenieros. Por lo tanto, tenían que mantener un registro de todos los documentos que debían imprimirse para garantizar que tuvieran el aspecto que debían cuando se imprimieran.

“Cuadro de video” es también un documento que se mostró en una pantalla de texto. Las pantallas no siempre admitían los caracteres requeridos y la cantidad requerida de caracteres horizontales y líneas verticales (y no admitían gráficos en absoluto). Por lo tanto, también en este caso era necesario coordinar adicionalmente las formas de todos los documentos en pantalla.

Ahora las palabras “maquineograma”, “cuadro de video”, “ADC” ya no nos dicen nada. Tampoco los encontré en uso, aunque me gradué en un instituto especializado en los años 90. Fue la época de la aparición de Windows 3.1, las pantallas VGA, los disquetes de tres pulgadas y los primeros sitios de Internet nacionales. Pero estas palabras están en el estándar y el cliente a veces exige caprichosamente que le proporcionemos un conjunto completo de documentación de acuerdo con GOST 34.201-89. Es más, tales formulaciones en los TdR migran de un ministerio a otro y ya se han convertido en una especie de plantilla tácita en la que se introduce el contenido.

Por lo tanto, el documento con el estúpido nombre “Dibujo del formulario del documento (cuadro de video)” en el proyecto no debe y no debe estar vacío.

¿Qué hay de bueno en el estándar?

Cualquier estándar es bueno porque permite al cliente y al contratista hablar el mismo idioma y proporciona una garantía de que, al menos, el cliente no tendrá ninguna queja “en forma” sobre los resultados transmitidos.

Y los estándares GOST 34 también son buenos porque fueron compilados por personas inteligentes, probados a lo largo de los años y tienen un objetivo claro: describir en papel de la manera más completa posible la compleja esencia abstracta que representa cualquier sistema de control automatizado.

Cuando necesite establecer de manera competente una tarea para contratistas occidentales que nunca han oído hablar de nuestros estándares GOST, también puede confiar en estos estándares, o más bien en su contenido y componente semántico. Porque, repito, la garantía de integridad de la información vale mucho. Por mucho que nos enorgullezcamos del alto nivel de nuestra profesionalidad, es posible que nos olvidemos de incluir cosas elementales en nuestros requisitos, mientras que el mismo GOST 34.602-89 "recuerda" todo. Si no tiene claro cómo debería ser el resultado del trabajo de los contratistas occidentales, consulte los requisitos de documentación y las secciones recomendadas. ¡Te lo aseguro, es mejor no pensar en ello! Lo más probable es que existan análogos occidentales de nuestros estándares, en los que todo puede ser más completo, más moderno y mejor. Desafortunadamente, no los conozco, ya que hasta ahora no ha habido un solo caso en el que nuestros estándares GOST no fueran suficientes.

Puede reírse del hecho de que los creadores de estándares no sabían nada sobre Java o .NET, sobre monitores HD e Internet, pero no recomendaría subestimar la escala del trabajo que hicieron y su valor para nuestra comunidad profesional.

Cómo leer y comprender los estándares de documentación según GOST serie 34

La norma divide todos los documentos en dos ejes: tiempo y área temática. Si observa la Tabla 2 en GOST 34.201-89, puede ver claramente esta división (columnas "Etapa de creación" y "Parte del proyecto"

Etapas de la creación de un sistema de control automatizado.

Las etapas de creación se definen en GOST 34.601-90. Tres de ellos son relevantes para la documentación:

• Anteproyecto de diseño (ED)
• Diseño técnico (TP)
• Elaboración de documentación de trabajo (DD)

Diseño preliminar sigue a la etapa de Especificaciones Técnicas y sirve para desarrollar soluciones de diseño preliminares.

Proyecto técnico Describe el futuro sistema desde todos los ángulos. Los documentos en la etapa TP deben, después de su lectura, dejar completa claridad en los enfoques, métodos y soluciones arquitectónicas y técnicas propuestas. En la siguiente fase, será demasiado tarde para describir enfoques y justificar soluciones técnicas, por lo que la fase P es la clave para la finalización exitosa del trabajo, ya que toda la variedad de requisitos de las especificaciones técnicas deben reflejarse en los documentos de la fase P. En la fase P, es posible que el sistema no exista en absoluto.

Documentación de trabajo diseñado para el exitoso despliegue, puesta en servicio y posterior funcionamiento del nuevo sistema. Se trata de documentos que contienen información muy específica que describe entidades físicamente existentes, a diferencia de la fase P, que describe el esplendor futuro.

Partes (secciones) de la documentación del proyecto para la creación de un sistema de control automatizado.

El área temática se divide en “Disposiciones”. A primera vista parece que tal división es redundante e innecesaria. Pero cuando se empieza a trabajar con este conjunto de herramientas en la práctica, la ideología que contiene se va aclarando poco a poco.

Un sistema automatizado, tal como lo definen los compiladores de GOST, es una combinación de hardware, software y canales de comunicación que procesa información proveniente de diferentes fuentes de acuerdo con ciertos algoritmos y produce resultados de procesamiento en forma de documentos, estructuras de datos o acciones de control. Un modelo primitivo de la ametralladora más simple.

Para describir completamente esta “máquina”, se realizan las siguientes secciones (como en el dibujo):

Software (MS), respondiendo a las preguntas: ¿qué lógica está cableada dentro de la “caja negra”? ¿Por qué se eligieron estos algoritmos particulares, estas fórmulas particulares y estos coeficientes particulares?

El software matemático no sabe nada sobre procesadores o bases de datos. Esta es un área abstracta separada, la morada de los "caballos esféricos en el vacío". Pero el software matemático puede estar muy relacionado con el área temática, también conocida como Vida Real. Por ejemplo, los algoritmos de control para los sistemas de control de tráfico deben ser aprobados por la Inspección Estatal de Seguridad del Tráfico antes de que sean aprobados por el cliente. Y entonces entiendes por qué están incluidos en un libro aparte. Porque a nadie en la policía de tránsito le interesa en qué sistema operativo se ejecutará el servidor de aplicaciones, pero es muy interesante qué señal y límite de velocidad aparecerán en el tablero bajo la lluvia o la nieve. Ellos son responsables de su parte y no van a firmar nada más. Por otro lado, cuando firmen, no habrá dudas sobre el aspecto técnico de la cuestión: por qué eligieron esos tableros o semáforos y no otros. La sabiduría de los “antepasados” se manifiesta precisamente en estos casos prácticos.

Soporte de información (IS). Otra porción del sistema. Esta vez la caja negra de nuestro sistema se vuelve transparente y observamos la información que circula en ella. Imaginemos un modelo del sistema circulatorio humano en el que todos los demás órganos sean invisibles. Algo así es el soporte informativo. Describe la composición y las rutas del flujo de información dentro y fuera, la organización lógica de la información en el sistema, una descripción de libros de referencia y sistemas de codificación (quienes crearon programas para producción saben lo importantes que son). La parte descriptiva principal recae en la etapa TP, pero algunos “rudimentos” fluyen hacia la etapa RD, como el documento “Catálogo de base de datos”. Está claro que anteriormente contenía exactamente lo que está escrito en el título. Pero hoy intentamos crear un documento de este tipo para un sistema complejo y complejo, cuando muy a menudo el sistema utiliza subsistemas comprados con sus propios almacenes de información misteriosos. Ni siquiera digo que este documento no sea especialmente necesario ahora.

O aquí está la "Declaración de medios de almacenamiento informático". Está claro que anteriormente contenía numerosos tambores magnéticos o bobinas de película. Ahora ¿qué debo poner ahí?

En definitiva, en la fase de RD, los documentos de soporte informativo representan un rudimento bastante nocivo, ya que formalmente deberían existir, pero no hay nada especial con qué llenarlos.

Software. La parte favorita de todos de la documentación del proyecto. ¡Sí, aunque sólo sea porque es un solo documento! Y entonces todos entienden lo que hay que escribir allí. Pero lo repetiré de todos modos.

En este documento debemos indicarle con ayuda de qué software se ejecutan los algoritmos descritos en el ML, procesando la información descrita en el IR. Es decir, no es necesario duplicar aquí información de otras secciones. Aquí se proporciona la arquitectura del sistema, la justificación de las tecnologías de software seleccionadas, su descripción (todo tipo de elementos del sistema: lenguajes de programación, frameworks, sistemas operativos, etc.). También en este documento describimos cómo se organizan las herramientas de procesamiento de información (colas de mensajes, almacenamiento, herramientas de respaldo, soluciones de disponibilidad, todo tipo de grupos de aplicaciones, etc.). La norma contiene una descripción detallada del contenido de este documento, que cualquier especialista comprenderá.

Soporte técnico (TO). Una parte no menos querida de la documentación del proyecto. El panorama halagüeño sólo se ve empañado por la abundancia de documentos que es necesario desarrollar. En total, la norma requiere la elaboración de 22 documentos, de los cuales 9 se encuentran en etapa de CT.

El hecho es que el estándar proporciona una descripción de todo el soporte técnico, incluido el hardware y las redes informáticas, los sistemas de ingeniería e incluso la parte de construcción (si es necesario). Y esta economía está regulada por una gran cantidad de normas y regulaciones, coordinadas en diferentes organizaciones, y por lo tanto es más conveniente dividir todo en partes y coordinar (editar) en partes. Al mismo tiempo, el estándar le permite combinar algunos documentos entre sí, lo que tiene sentido si todos son aprobados por una sola persona.

No olvide también que un conjunto de estándares de calidad implica el registro y almacenamiento de documentos técnicos, y nuestros "libros" del cliente pueden distribuirse en diferentes archivos, dependiendo del tema de la descripción. Este es otro argumento a favor de la fragmentación de la documentación.

Apoyo organizacional (OO). Habiendo reprimido el deseo, normal en un técnico, de saltarnos este apartado lo más rápido posible, por el contrario, lo consideraré con más detalle. Desde entonces, colegas, recientemente ha habido algunas malas tendencias en proyectos que requieren una aclaración en esta sección.

En la etapa TP, la sección contiene solo un documento " Descripción de la estructura organizativa.", en el que debemos decirle al cliente para qué debe prepararse en términos de cambio de estructura organizativa. De repente necesitas organizar un nuevo departamento para operar tu sistema, introducir nuevos puestos, etc.

En la etapa de RD aparecen otros documentos más interesantes, que me gustaría considerar por separado.

Guía del usuario. Los comentarios son innecesarios, creo.

Metodología (tecnología) del diseño asistido por computadora.. Si es necesario, puede incluir una descripción del proceso de creación de software, control de versiones, pruebas, etc. en este documento. Pero esto es así si el cliente, según las especificaciones técnicas, desea montar personalmente el software. Si él no lo requiere (y no lo paga), entonces toda su cocina interna no es de su incumbencia y no es necesario realizar este documento.

Instrucciones tecnológicas. Debido a la moda de formalizar los procesos comerciales, un cliente astuto a veces intenta incluir normas operativas en este documento. Por lo tanto, bajo ninguna circunstancia debes hacer esto.

Descripción de procesos comerciales, descripciones de roles y puestos, regulaciones laborales: todo esto es ORD, es decir, documentación organizativa y administrativa. El cual es producto de un proyecto de consultoría, que hasta donde tengo entendido no fue comprado a ustedes. Y te compraron un proyecto técnico y también documentación técnica.

La instrucción tecnológica es una capa entre las instrucciones de funcionamiento y el manual de usuario. El RP describe en detalle Cómo necesitas realizar ciertas acciones en el sistema. La instrucción tecnológica dice que cual Se deben realizar acciones en determinados casos relacionados con el funcionamiento del sistema. En términos generales, una instrucción tecnológica es un breve resumen de RP para un puesto o rol específico. Si el cliente no tiene roles formados o quiere que usted mismo cree roles y requisitos laborales, incluya los roles más básicos en el documento, por ejemplo: operador, operador senior, administrador. Los comentarios del cliente sobre el tema "pero con nosotros no es así" o "no nos gusta" deben ir acompañados de una lista de funciones y una descripción de las responsabilidades laborales. Porque los procesos de negocio que no lo ponemos. Somos estos procesos de negocio. automatizar.

Escribiré sobre los rastrillos descritos por separado, con ejemplos coloridos, ya que no es la primera vez que esto se repite en diferentes sectores de la "economía nacional".

Descripción del proceso tecnológico de procesamiento de datos (incluido el teleprocesamiento). Una patética reliquia de la época de las cavernas, cuando había "operadores informáticos" especialmente designados que alimentaban la máquina con tarjetas perforadas y empaquetaban una copia impresa del resultado en un sobre. Esta instrucción es para ellos. No puedo decirte exactamente qué escribir en él en el siglo XXI. Sal tú mismo. Lo mejor es olvidarse de este documento.

Soluciones para todo el sistema (WSO). La norma prevé 17 documentos en la sección OP. En primer lugar, estos son casi todos documentos de la fase preliminar del Diseño Esquemático. En segundo lugar, se trata de todo tipo de estimaciones, cálculos y breves descripciones de funciones automatizadas. Es decir, información para personas que no pertenecen a la producción principal de TI, sino para el personal de apoyo: gerentes, estimadores, especialistas en compras, economistas, etc.

Y en tercer lugar, el OP incluye un megadocumento llamado "Nota explicativa del proyecto técnico", que pretende ser una especie de resumen ejecutivo, pero de hecho, muchos diseñadores incluyen en él todo el contenido útil de la etapa TP. Un enfoque tan radical puede estar justificado e incluso ser mutuamente beneficioso tanto para el cliente como para el contratista, pero en determinados casos.

Opciones para usar GOST 34

1. Cumplimiento total y exacto de la norma. Naturalmente, nadie escribirá voluntariamente tal nube de documentos. Por lo tanto, un juego completo de documentos se prepara solo a petición urgente del cliente, que aseguró en las especificaciones técnicas y también se fija en el acuerdo en la parte superior. En este caso, debe tomar todo literalmente y entregarle al cliente "libros" físicos, en los que estarán los nombres de los documentos de la Tabla 2 de GOST 34.201-89, con la excepción de los completamente innecesarios, cuya lista usted debe discutir y asegurar por escrito. El contenido de los documentos también debe, sin imaginación alguna, cumplir con el RD 50-34.698-90, hasta los nombres de las secciones. Para hacer explotar el cerebro del cliente, a veces un sistema grande se divide en subsistemas y se emite documentación de diseño separada para cada subsistema. Parece aterrador y no está sujeto al control normal con la ayuda de la mente terrenal. Especialmente en lo que respecta a la integración de subsistemas. Lo que simplifica enormemente la aceptación. Lo principal es que usted mismo no se confunda y que su sistema siga funcionando como debería.
2. Nos encantan los estándares GOST. Las grandes empresas serias aman los estándares. Porque ayudan a las personas a entenderse mejor. Si su cliente se caracteriza por su amor por el orden y la estandarización, intente adherirse a la ideología estándar GOST al desarrollar documentos, incluso si las especificaciones técnicas no lo exigen. Los especialistas que lo aprueban lo comprenderán y lo aprobarán mejor, y usted mismo no olvidará incluir información importante en la documentación, verá mejor la estructura objetivo de los documentos, planificará con mayor precisión el trabajo de redactarlos y se salvará a sí mismo y a tus compañeros muchos nervios y dinero.
3. No nos importa la documentación, siempre y cuando todo funcione.. La desaparición del cliente irresponsable. Todavía se puede encontrar una visión similar de la documentación entre los clientes pequeños y pobres, así como en las "idiotocracias" autoritarias que quedaron de la época de la perestroika, donde el jefe está rodeado de amigos leales, los directores, y todos los problemas se resuelven en conversaciones personales. . En tales condiciones, es libre de descuidar la documentación por completo, pero es mejor, después de todo, no derribar la vista y al menos completar esquemáticamente la documentación con contenido. Si no es para este cliente, páselo (véndalo) al siguiente.

Conclusión

Este artículo trataba sobre nuestros estándares GOST para documentar sistemas de control automatizados. Los GOST son antiguos, pero resulta que siguen siendo muy útiles en el hogar. Aparte de algunos rudimentos obvios, la estructura de la documentación tiene las propiedades de ser completa y coherente, y el cumplimiento de la norma elimina muchos riesgos del proyecto, cuya existencia tal vez no conocemos al principio.

Espero que el material presentado te haya resultado útil, o al menos interesante. A pesar del aparente tedio, la documentación es un trabajo importante y responsable, en el que la precisión es tan importante como escribir un buen código. ¡Escriban buenos documentos, colegas! Y la semana que viene haré dos viajes de negocios seguidos, por lo que no puedo garantizar la publicación de nuevos materiales (no tengo caché, escribo mentalmente).

Introducción

En el mundo moderno, cada día aparecen decenas y cientos de programas, aplicaciones y sistemas de información diferentes. Pueden desarrollarse para el sector gubernamental o comercial, así como para usuarios comunes. El 90% de todos los usuarios no lee la documentación, la considera aburrida, tediosa y poco interesante, y abre el manual de usuario solo cuando algo no funciona o es completamente imposible entenderlo sin instrucciones. Ahora es una práctica común diseñar la interfaz de usuario de tal manera que sea intuitiva y el usuario pueda entender el sistema sin tener que leer largos manuales. Sin embargo, cuando se trabaja con grandes clientes, casi siempre es necesario presentar un determinado paquete de documentos: manuales, instrucciones, soluciones de diseño, redactados de acuerdo con GOST.
Cuando te encuentras por primera vez con la escritura de documentación según GOST, te quedas estupefacto y completamente impactado, ya que hay un “mar” de estos GOST y cómo y qué escribir según ellos se vuelve confuso.
Este artículo analiza los estándares GOST para redactar documentación y sus puntos principales.

¿Cuáles son los estándares GOST?

Primero, debe comprender qué son los estándares GOST. Todo el mundo sabe que GOST es algo que se desarrolló en el marco de la Unión y que simplemente hay un número infinito de ellos. Me apresuro a asegurarles que no hay muchos GOST para el sector de TI y que todos ellos, a pesar de su tiempo de creación, no han perdido su relevancia.
En primer lugar, los estándares para redactar documentación se dividen en dos tipos:

1. Estándares internacionales (ISO, IEEE Std);
2. GOST rusos o soviéticos.

Estándares internacionales
Los estándares internacionales se utilizan para desarrollar documentación a nivel internacional. Por regla general, no son gratuitos, ya que no son desarrollados por organizaciones gubernamentales, pero, a diferencia de los nuestros, fueron desarrollados recientemente. El tema de las normas internacionales es muy amplio, por lo que será tratado en otro artículo. También se abordan varios estándares que están estrechamente relacionados con la redacción de documentación.
Lista de los principales estándares internacionales para la redacción de documentación:

1. IEEE Std 1063-2001 “Estándar IEEE para documentación de usuario de software”: estándar para escribir manuales de usuario;
2. IEEE Std 1016-1998 “Práctica recomendada de IEEE para descripciones de diseño de software”: un estándar para escribir una descripción técnica de un programa;
3. ISO/IEC FDIS 18019:2004 “Directrices para el diseño y preparación de documentación de usuario para software de aplicación” es otro estándar para escribir manuales de usuario. Hay una gran cantidad de ejemplos en este documento. Por así decirlo, esto es más bien una guía para escribir un manual de usuario. Será especialmente útil para especialistas novatos;
4. ISO/IEC 26514:2008 “Requisitos para diseñadores y desarrolladores de documentación de usuario” es otro estándar para diseñadores y desarrolladores de documentación de usuario.

En realidad, existen muchos estándares internacionales y cada país tiene el suyo propio, ya que es posible que el mismo estándar no siempre se adapte tanto a las empresas europeas como a las asiáticas.

estándares rusos
Los estándares rusos se desarrollan a nivel estatal. Todos son absolutamente gratuitos y cada uno de ellos es fácil de encontrar en Internet. Para redactar la documentación del programa, se utilizan dos series de GOST 19 y 34. Son estos los que se analizarán más a fondo.

¿Cuál es la diferencia entre GOST series 19 y 34?

La primera pregunta que surge es en qué se diferencian, en general, estos GOST 19 y 34 entre sí.
En GOST 19.781-90 “Sistema unificado de documentación de programas. Software para sistemas de procesamiento de información. Términos y definiciones" se indican las definiciones:

1. Programa: datos destinados a controlar componentes específicos de un sistema de procesamiento de información para implementar un algoritmo específico.
2. El software es un conjunto de programas de sistemas de procesamiento de información y documentos de programas necesarios para el funcionamiento de estos programas.

En GOST 34.003-90 “Tecnología de la información. Conjunto de normas para sistemas automatizados. Sistemas automatizados. Términos y definiciones" se indica la definición:

1. Sistema automatizado (AS): un sistema compuesto por personal y un conjunto de herramientas de automatización para sus actividades, que implementa tecnología de la información para realizar funciones establecidas.
   Dependiendo del tipo de actividad, se distinguen, por ejemplo, los siguientes tipos de AS: sistemas de control automatizados (ACS), sistemas de diseño asistido por computadora (CAD), sistemas automatizados de investigación científica (ASRS) y otros.

Dependiendo del tipo de objeto controlado (proceso), los sistemas de control automatizados se dividen, por ejemplo, en: sistemas de control automatizados para procesos tecnológicos (ACS), sistemas de control automatizados para empresas (ACS), etc.
GOST 34 también hace una división en tipos de soporte AS:

1. Organizativo;
2. Metódico;
3. Técnico;
4. Matemático;
5. Software;
6. Informativo;
7. Lingüístico;
8. Legal;
9. Ergonómico.

Como resultado, un Sistema Automatizado no es un programa, sino un complejo de tipos de software, incluido el software. AS, por regla general, ofrece una solución organizativa para un usuario y cliente específico, y el Programa se puede crear y replicar para una gran cantidad de usuarios sin estar vinculado a ninguna empresa.
Por lo tanto, si está desarrollando documentación para un programa que creó para una empresa específica, entonces su GOST es 34. Si está escribiendo documentos para un programa masivo, entonces su GOST es 19.

GOST 34

La serie GOST 34 (Estándares de tecnología de la información GOST 34.xxx) consta de:

1. GOST 34.201-89 Tipos, integridad y designaciones de documentos al crear sistemas automatizados: esta norma establece los tipos, el nombre, la integridad y el número de documentos. Es uno de los documentos principales de la serie GOST 34. De hecho, este es un documento básico, por lo que los principiantes deben familiarizarse con él primero.
2. GOST 34.320-96 Conceptos y terminología para esquemas conceptuales y bases de información: esta norma establece los conceptos y términos básicos de esquemas conceptuales y bases de información, que cubre el desarrollo, descripción y aplicación de esquemas conceptuales y bases de información, manipulación de información, así como la descripción e implementación del proceso de información. La norma define el papel del diagrama conceptual. Las disposiciones contenidas en él tienen carácter consultivo y pueden utilizarse para evaluar los sistemas de gestión de bases de datos (DBMS). Este documento no describe métodos específicos para utilizar herramientas de soporte de diagramas conceptuales. Los lenguajes de esquemas conceptuales descritos en el estándar no deben considerarse lenguajes estándar.
3. GOST 34.321-96 Tecnologías de la información. Sistema de estándares de bases de datos. Modelo de referencia de gobernanza: este documento establece un modelo de referencia de gobernanza de datos.
   El modelo de referencia define terminología y conceptos comunes relacionados con los datos de los sistemas de información. Estos conceptos se utilizan para definir los servicios proporcionados por los sistemas de gestión de bases de datos o los sistemas de diccionario de datos.
   El modelo de referencia no considera protocolos para la gestión de datos.
   El alcance del modelo de referencia incluye procesos que se ocupan de la gestión de datos persistentes y su interacción con procesos distintos de los requisitos de un sistema de información específico, así como servicios generales de gestión de datos para definir, almacenar, recuperar, actualizar, ingresar, copiar. , restauración y transmisión de datos.
4. GOST 34.601-90 Sistemas automatizados. Etapas de creación: el estándar establece las etapas y etapas de la creación de un AS.
5. GOST 34.602-89 Especificaciones técnicas para la creación de un sistema automatizado (en lugar de GOST 24.201-85): establece la composición, el contenido y las reglas para la elaboración del documento “Términos de referencia para la creación (desarrollo o modernización) del sistema. "
   Este documento es uno de los documentos de uso frecuente de la serie GOST 34. Al desarrollar especificaciones técnicas para este GOST, debe recordar otros estándares, incluso si este documento no contiene referencias a estos estándares.
6. GOST 34.603-92 Tecnología de la información. Tipos de pruebas de sistemas automatizados: la norma establece tipos de pruebas de AS (autónomas, complejas, pruebas de aceptación y operación de prueba) y requisitos generales para su implementación.
7. RD 50-34.698-90 Sistemas automatizados. Los requisitos para el contenido de los documentos son uno de los documentos más importantes de GOST 34, ya que describe el contenido de casi todos los documentos, así como una descripción de cada párrafo del documento.
8. GOST R ISO/IEC 8824-3-2002 Tecnología de la información. Notación de sintaxis abstracta versión uno: este estándar es parte de la notación de sintaxis abstracta versión 1 (ASN.1) y establece una notación para la especificación de restricciones definidas por el usuario y restricciones de tabla.
9. GOST R ISO/IEC 10746-3-2001 Gestión de datos y procesamiento distribuido abierto.
   En esta norma:
   • se determina cómo se especifican los sistemas de procesamiento distribuido abierto (ODP) utilizando los conceptos introducidos en GOST R ISO/IEC 10746-2;
   • Se han identificado las características según las cuales los sistemas pertenecen a los sistemas OPO.

   La norma establece un marco para coordinar el desarrollo de normas para sistemas ODP.

10. GOST R ISO/IEC 15271-02 Procesos del ciclo de vida del software: en mi opinión, este GOST es más necesario para los analistas a la hora de diseñar y modelar AS.
    Este documento es útil, desde mi punto de vista, con fines puramente educativos.
11. GOST R ISO/IEC 15910-2002 Proceso para crear documentación de usuario para una herramienta de software: define el proceso mínimo requerido para crear documentación de usuario de todo tipo para una herramienta de software que tiene una interfaz de usuario. Estos tipos incluyen documentación impresa (por ejemplo, guías de usuario y tarjetas de referencia rápida), documentación en línea, texto de ayuda y sistemas de documentación en línea.

Entonces, según todo lo escrito anteriormente, está claro que los documentos principales en GOST 34 son 3: GOST 34.201-89, RD 50-34.698-90 y GOST 34.602-89.
Al desarrollar un paquete de documentación, primero debe abrir GOST 34.201-89 y seleccionar la etapa de creación: borrador de diseño, diseño técnico y documentación de trabajo. A continuación, debe seleccionar los documentos para el desarrollo que correspondan a la etapa de creación.

Lista de documentos 34 GOST

Escenario creación	Título del documento	Código	Parte proyecto	Prinad cama a proyecto pero-estimación Noah Doku policía ciones	Prinad cama a explotación estación noé arriba kumen taciones	Instrucciones adicionales
PE	Hoja de diseño preliminar	PE*	O	—	—	—
	Nota explicativa Al diseño preliminar	P1	O	—	—	—
PE, TP	Organigrama	CO	O	—	—	Se permite incluir P3 o PV en el documento.
	Diagrama estructural del complejo. medios tecnicos	C1*	ESO	X	—
	Diagrama de estructura funcional	C2*	O	—	—	Al desarrollar los documentos CO, C1, C2, C3 en la etapa ES, se permite incluirlos en el documento P1.
	especializado (nuevo) medios tecnicos	A LAS 9	ESO	X	—	Al desarrollar en la etapa técnica. permitido incluir documentar P2
	Esquema de automatización	C3*	ESO	X	—	—
	Especificaciones técnicas para el desarrollo. especializado (nuevo) medios tecnicos	—	ESO	—	—	El proyecto no incluye
TP	Tareas de desarrollo sanitario y otras secciones relacionado con el proyecto con la creación del sistema	—	ESO	X	—	El proyecto no incluye
	Ficha de diseño técnico	TP*	O	—	—	—
	Lista de artículos comprados	Vicepresidente*	O	—	—	—
	Lista de señales de entrada y datos	EN 1	Y SOBRE	—	—	—
	Lista de señales de salida (documentos)	A LAS 2	Y SOBRE	—	—	—
	Lista de tareas de desarrollo construcción, electricidad, sanitario y otras secciones relacionado con el proyecto con la creación del sistema	A LAS 3	ESO	X	—	Se permite incluir P2 en el documento.
	Nota explicativa al proyecto técnico	P2	O	—	—	Incluye plan de eventos sobre la preparación de un objeto para la entrada sistemas en funcionamiento
	Descripción de automatizado funciones	P3	O	—	—	—
	Descripción de la configuración de la tarea. (conjunto de tareas)	P4	O	—	—	Permitido incluir a los documentos P2 o P3
	Descripción de la información asegurando el sistema	P5	Y SOBRE	—	—	—
	Descripción de la organización base de información	P6	Y SOBRE	—	—	—
TP	Descripción de los sistemas de clasificación y codificación	P7	Y SOBRE	—	—	—
	Descripción de la matriz información	P8	Y SOBRE	—	—	—
	Descripción del complejo medios tecnicos	P9	ESO	—	—	Para la tarea se permite incluir en el documento 46 según GOST 19.101
	Descripción del software disposición	Pensilvania	POR	—	—	—
	Descripción del algoritmo (procedimiento del proyecto)	PB	mes	—	—	Se permite incluir P2, P3 o P4 en los documentos.
	Descripción de la organización estructuras	fotovoltaica	OOO	—	—	—
	Plan de diseño	C8	ESO	X	—	Está permitido incluir P9 en el documento.
	Lista de equipo y materiales	—	ESO	X	—	—
	Cálculo de estimación local	B2	O	X	—	—
TP, RD	Evaluación de proyectos confiabilidad del sistema	B1	O	—	—	—
	Dibujo de formulario de documento (fotograma de vídeo)	C9	Y SOBRE	—	X	En la etapa TP está permitido. incluir en los documentos P4 o P5
RD	Lista de titulares originales	DP*	O	—	—	—
	Ficha operativa documentos	DE*	O	—	X	—
	Especificación de hardware	A LAS 4	ESO	X	—	—
	Lista de requisitos en materiales	A LAS 5	ESO	X	—	—
	Inventario de medios de la máquina información	máquina virtual*	Y SOBRE	—	X	—
	Matriz de entrada	A LAS 6	Y SOBRE	—	X	—
RD	Directorio de base de datos	A LAS 7	Y SOBRE	—	X	—
	Composición de los datos de salida (mensajes)	A LAS 8	Y SOBRE	—	X	—
	Estimaciones locales	B3	O	X	—	—
	Metodología (tecnología) automatizado diseño	I1	OOO	—	X	—
	Instrucciones tecnológicas	Y 2	OOO	—	X	—
	Guía del usuario	I3	OOO	—	X	—
	Instrucciones para formar y mantenimiento de base de datos (conjunto de datos)	I4	Y SOBRE	—	X	—
	Instrucciones de funcionamiento KTS	ES DECIR	ESO	—	X	—
	Diagrama de cableado externo	C4*	ESO	X	—	Se permite realizar en en forma de tablas
	Diagrama de conexión publicaciones externas	C5*	ESO	X	—	Mismo
	Tabla de conexiones y conexiones.	C6	ESO	X	—	—
	Diagrama de división del sistema (estructural)	E1*	ESO	—	—	—
	dibujo general	EN*	ESO	X	—	—
	Plano de instalación del equipo técnico.	SA	ESO	X	—	—
	Diagrama esquemático	SB	ESO	X	—	—
	Diagrama estructural del complejo. medios tecnicos	C1*	ESO	X	—	—
	Plano de disposición de equipos y cableado.	C7	ESO	X	—	—
	Descripción de tecnológico proceso de procesamiento datos (incluyendo teleprocesamiento)	PG	OOO	—	X	—
	Descripción general del sistema.	PD	O	—	X	—
	Programa y metodología de pruebas (componentes, sistemas de automatización, subsistemas, sistemas)	PM*	O	—	—	—
	Forma	FO*	O	—	X	—
	Pasaporte	PD*	O	—	X	—
*Documentos cuyo código se establece de acuerdo con los requisitos de las normas ESKD

Nota a la mesa:

1. En la tabla se utilizan las siguientes notaciones:
   • EP - diseño preliminar;
   • TP - diseño técnico;
   • RD - documentación de trabajo;
   • O - soluciones para todo el sistema;
   • OO - decisiones sobre apoyo organizacional;
   • PARA - soluciones de soporte técnico;
   • IO - soluciones para soporte de información;
   • Software: soluciones de software;
   • MO - soluciones de software.
2. El signo X indica que pertenece a las estimaciones de diseño o documentación operativa.
3. La nomenclatura de los documentos del mismo nombre se establece en función de las decisiones de diseño tomadas durante la creación del sistema.

Cuando se haya determinado la lista de documentos, en el RD 50-34.698-90 se deben encontrar los documentos seleccionados y desarrollarlos estrictamente de acuerdo con los puntos especificados. Todos los puntos de contenido que se indican deben estar en el documento.
Si se están desarrollando las Especificaciones Técnicas, inmediatamente debe abrir GOST 34.602-89 y desarrollar las especificaciones técnicas estrictamente de acuerdo con los puntos.

GOST 19

La serie de GOST 19 (GOST 19.xxx Sistema unificado de documentación de programas (USPD)) consta de:

1. 1. GOST 19.001-77 Disposiciones generales: un documento demasiado general que no tiene ningún uso práctico. Por lo tanto, puedes omitirlo.
   2. GOST 19781-90 Términos y definiciones: una buena lista de definiciones en el campo del software para sistemas de procesamiento de información. No contiene más que definiciones.
   3. GOST 19.101-77 Tipos de programas y documentos de programas: uno de los documentos principales de 19 GOST. Aquí es donde debería comenzar a trabajar con GOST 19, ya que contiene una lista completa y designaciones de documentos GOST.

Lista de documentos 19 GOST

Código	Tipo de Documento	Etapas de desarrollo
		Incompleto proyecto	Técnico proyecto	Borrador de trabajo
				componente	complejo
—	Especificación	—	—
05	Lista de titulares originales	—	—	—
12	Texto del programa	—	—
13	Descripción del programa	—	—
20	Lista de documentos operativos	—	—
30	Forma	—	—
31	Descripción de la aplicación	—	—
32	Guía del programador del sistema	—	—
33	Guía del programador	—	—
34	Manual del operador	—	—
35	Descripción del idioma	—	—
46	Manual técnico servicio	—	—
51	Programa y metodología de prueba.	—	—
81	Nota explicativa			—	—
90-99	Otros documentos

Leyenda:
— el documento es obligatorio;
— el documento es obligatorio para los componentes que tienen un uso independiente;
— la necesidad de redactar un documento se determina en la etapa de elaboración y aprobación de las especificaciones técnicas;
- - el documento no está redactado.

1. GOST 19.102-77 Etapas de desarrollo: contiene una descripción de las etapas de desarrollo. Útil para fines educativos. En mi opinión, no tiene muchos beneficios prácticos.
2. GOST 19.103-77 Designaciones de programas y documentos de programas: contiene una descripción de cómo asignar un número (código) a un documento. Incluso después de leer este GOST, quedan muchas preguntas sobre cómo asignar este mismo número a un documento.
3. GOST 19.104-78 Inscripciones principales: establece los formularios, tamaños, ubicación y procedimiento para completar las inscripciones principales de la hoja de aprobación y la página de título en los documentos del programa previstos por las normas DEUC, independientemente de los métodos de su implementación. Dado que los documentos 19 GOST están redactados en marcos, este documento es muy importante.
4. GOST 19.105-78 Requisitos generales para documentos del programa: establece requisitos generales para la preparación de documentos del programa. Los requisitos son demasiado generales. Como regla general, este GOST casi no se utiliza para desarrollar un documento, ya que un GOST especial para un documento es suficiente, pero para el conocimiento general es mejor examinar este GOST una vez.
5. GOST 19.106-78 Requisitos para los documentos del programa ejecutados en forma impresa: contiene requisitos para la ejecución de todos los documentos 19 GOST.
6. GOST 19.201-78 Especificaciones técnicas, requisitos de contenido y diseño: establece el procedimiento para construir y preparar especificaciones técnicas para el desarrollo de un programa o producto de software.

   Los puntos de las especificaciones técnicas de 34 GOST y 19 GOST son diferentes.

7. GOST 19.601-78 Reglas generales para duplicación, contabilidad y almacenamiento: reglas generales para duplicación, circulación, contabilidad y almacenamiento de documentos del programa. GOST describe en varios puntos cómo garantizar que los documentos no se pierdan.
8. GOST 19.602-78 Reglas para duplicación, contabilidad y almacenamiento de documentos de programas, ejecuciones de impresión. Método: adición a GOST 19.601-78.
9. GOST 19.603-78 Reglas generales para realizar cambios: establece reglas generales para realizar cambios en los documentos del programa. En esencia, describe un largo algoritmo burocrático para realizar cambios en los documentos.
10. GOST 19.604-78 Reglas para realizar cambios en documentos de programa impresos: describe el procedimiento para trabajar y completar la Hoja de registro de cambios.

Una lista de GOST especializados, es decir, cada uno de ellos describe el contenido y los requisitos de un documento específico:

1. Especificación GOST 19.202-78. Requisitos de contenido y diseño;
2. GOST 19.301-79 Programa y metodología de prueba. Requisitos de contenido y diseño;
3. GOST 19.401-78 Texto del programa. Requisitos de contenido y diseño;
4. GOST 19.402-78 Descripción del programa;
5. GOST 19.403-79 Lista de titulares originales;
6. GOST 19.404-79 Nota explicativa. Requisitos de contenido y diseño;
7. Formulario GOST 19.501-78. Requisitos de contenido y diseño;
8. GOST 19.502-78 Descripción de la aplicación. Requisitos de contenido y diseño;
9. GOST 19.503-79 Guía del programador del sistema. Requisitos de contenido y diseño;
10. GOST 19.504-79 Guía del programador. Requisitos de contenido y diseño;
11. GOST 19.505-79 Manual del operador. Requisitos de contenido y diseño;
12. GOST 19.506-79 Descripción del idioma. Requisitos de contenido y diseño;
13. GOST 19.507-79 Declaración de documentos operativos;
14. GOST 19.508-79 Manual de mantenimiento. Requisitos de contenido y diseño.

Procedimiento para trabajar con 19 GOST:

1. En GOST 19.101-77, seleccione un documento y su código según la etapa de desarrollo.
2. Según GOST 19.103-77, asigne un número al documento.
3. Luego, de acuerdo con GOST 19.104-78 y 19.106-78, redactamos un documento.
4. De la lista especializada de GOST, debe seleccionar el que corresponda al documento que se está desarrollando.

Conclusión

¡GOST no da miedo y es fácil! Lo principal es comprender qué se debe escribir y qué GOST se utiliza para ello. Nuestros GOST principales 19 y 34 para redactar documentación son muy antiguos, pero siguen siendo relevantes hasta el día de hoy. Redactar la documentación según la norma elimina muchos problemas entre el contratista y el cliente. En consecuencia, ahorra tiempo y dinero.

Fecha de introducción 01/01/92

Esta norma se aplica a los sistemas automatizados (AS) utilizados en diversos tipos de actividades (investigación, diseño, gestión, etc.), incluidas sus combinaciones creadas en organizaciones, asociaciones y empresas (en adelante, organizaciones).

La norma establece las etapas y etapas de la creación de un AS. El Apéndice 1 muestra el contenido del trabajo en cada etapa.

1. Disposiciones generales

2. Etapas y etapas de la creación de un AS

Apéndice 1 (para referencia)

Apéndice 2 (referencia)

1. DISPOSICIONES GENERALES

1.1. Es un conjunto de obras ordenadas en el tiempo, interconectadas, combinadas en etapas y fases, cuya ejecución es necesaria y suficiente para crear un sistema automatizado que cumpla con los requisitos especificados.

1.2. Las etapas y fases de la creación de un AS se distinguen como partes del proceso de creación por razones de planificación y organización racional del trabajo que finaliza con un resultado determinado.

1.3. El trabajo en el desarrollo del AS se lleva a cabo de acuerdo con las etapas y pasos utilizados para crear el AS.

1.4. La composición y reglas para realizar el trabajo en las etapas y etapas establecidas por esta norma se determinan en la documentación relevante de las organizaciones involucradas en la creación de tipos específicos de centrales nucleares.

La lista de organizaciones involucradas en la creación de centrales nucleares figura en el Apéndice 2.

2. ETAPAS Y ETAPAS DE CREACIÓN DE AS

2.1. Las etapas y etapas de la creación de un AS se muestran generalmente en la tabla.

Etapas	Etapas de trabajo
1. Formación de requisitos para los ponentes.	1.1. Inspección de la instalación y justificación de la necesidad de crear una central nuclear
	1.2. Formación de requisitos de usuario para hablantes.
	1.3. Elaboración de un informe sobre el trabajo realizado y una solicitud para el desarrollo de un AS (especificaciones tácticas y técnicas)
2. Desarrollo del concepto de CA	2.1. Estudiando el objeto
	2.2. Realizar los trabajos de investigación necesarios.
	2.3. Desarrollo de opciones de concepto de CA y selección de una opción de concepto de CA que cumpla con los requisitos del usuario.
	2.4. Elaboración de un informe sobre el trabajo realizado.
3. Términos de referencia	3.1. Elaboración y aprobación de especificaciones técnicas para la creación de centrales nucleares.
4. Anteproyecto de diseño	4.1. Desarrollo de soluciones de diseño preliminar para el sistema y sus partes.
	4.2. Desarrollo de documentación para el sistema de altavoces y sus partes.
5. Diseño técnico	5.1. Desarrollo de soluciones de diseño para el sistema y sus partes.
	5.2. Desarrollo de documentación para el sistema de altavoces y sus partes.
	5.3. Desarrollo y ejecución de documentación para el suministro de productos para la ejecución de la CN y (o) requisitos técnicos (especificaciones técnicas) para su desarrollo.
	5.4. Desarrollo de tareas de diseño en partes adyacentes del proyecto de instalación de automatización.
6. Documentación de trabajo	6.1. Desarrollo de documentación de trabajo para el sistema y sus partes.
	6.2. Desarrollo o adaptación de programas.
7. Aportaciones y acciones	7.1. Preparación del objeto de automatización para la puesta en funcionamiento de la central nuclear.
	7.2. Capacitación del personal
	7.3. Juego completo de parlantes con productos suministrados (software y hardware, sistemas de software y hardware, productos de información)
	7.4. Trabajos de construcción e instalación.
	7.5. Trabajos de puesta en servicio
	7.6. Realización de pruebas preliminares.
	7.7. Realización de una operación de prueba.
	7.8. Realización de pruebas de aceptación.
8. Soporte de CA	8.1. Realizar trabajos de acuerdo con las obligaciones de garantía.
	8.2. Servicio posgarantía

2.2. Las etapas e hitos que realizan las organizaciones que participan en la creación de centrales nucleares se establecen en contratos y especificaciones técnicas con base en esta norma.

Es posible excluir la etapa de "Diseño de croquis" y las etapas individuales de trabajo en todas las etapas, para combinar las etapas de "Diseño técnico" y "Documentación de trabajo" en una etapa de "Diseño técnico detallado". Dependiendo de las particularidades del AS que se está creando y las condiciones para su creación, se permite realizar etapas individuales de trabajo antes de la finalización de las etapas anteriores, la ejecución paralela de etapas de trabajo o la inclusión de nuevas etapas de trabajo.

APÉNDICE 1. Para referencia

1. En la etapa 1.1 “Inspección de la instalación y justificación de la necesidad de creación de una CN”, en el caso general se realiza lo siguiente:

• recopilación de datos sobre el objeto de automatización y los tipos de actividades realizadas;
• evaluar la calidad del funcionamiento de la instalación y los tipos de actividades realizadas, identificando problemas que pueden resolverse mediante herramientas de automatización;
• Evaluación (técnica, económica, social, etc.) de la viabilidad de creación de una central nuclear.

2. En la etapa 1.2 “formación de requisitos de los usuarios para los hablantes” se lleva a cabo lo siguiente:

• preparación de datos iniciales para la formación de requisitos para el sistema automatizado (características del objeto de automatización, descripción de los requisitos del sistema, limitaciones de los costos aceptables para el desarrollo, puesta en servicio y operación, el efecto esperado del sistema, condiciones para la creación y funcionamiento del sistema);
• Formulación y ejecución de requisitos de usuario para locutores.

3. En la etapa 1.3 “Completar un informe sobre el trabajo realizado y una solicitud para el desarrollo de un AS (especificaciones tácticas y técnicas)”, un informe sobre el trabajo realizado en esta etapa y una solicitud para el desarrollo de un AS (especificaciones tácticas) y especificaciones técnicas) u otro documento que lo sustituya se completan con contenido similar.

4. En las etapas 2.1 "Estudio del objeto" y 2.2 "Realización del trabajo de investigación necesario", la organización de desarrollo lleva a cabo un estudio detallado del objeto de automatización y el trabajo de investigación (I + D) necesario relacionado con la búsqueda de formas y la evaluación de la posibilidad de implementar los requisitos de los usuarios, elaborar y aprobar informes de investigación.

5. En la etapa 2.3 “Desarrollo de opciones para el concepto de AS y selección de una opción para el concepto de AS que cumpla con los requisitos del usuario”, en el caso general, se presentan opciones alternativas para el concepto de AS que se está creando y los planes para su implementación. desarrollado; evaluación de los recursos necesarios para su implementación y mantenimiento; evaluar las ventajas y desventajas de cada opción; comparación de los requisitos del usuario y las características del sistema propuesto y selección de la opción óptima; determinar el procedimiento para evaluar la calidad y las condiciones de aceptación del sistema; evaluación de los efectos obtenidos del sistema.

6. En la etapa 2.4 “Preparar un informe sobre el trabajo realizado”, preparar y redactar un informe que contenga una descripción del trabajo realizado en la etapa, una descripción y justificación de la versión propuesta del concepto del sistema.

7. En la etapa 3.1 “Desarrollo y aprobación de especificaciones técnicas para la creación de una central nuclear”, el desarrollo, ejecución, coordinación y aprobación de especificaciones técnicas para la central nuclear y, de ser necesario, especificaciones técnicas para partes de la central nuclear. Se llevan a cabo centrales eléctricas.

8. En la etapa 4.1 “Desarrollo de soluciones de diseño preliminares para el sistema y sus partes” se determinan: las funciones del AS; funciones de los subsistemas, sus objetivos y efectos; composición de complejos de tareas y tareas individuales; conceptos de la base de información, su estructura ampliada; funciones del sistema de gestión de bases de datos; composición del sistema informático; Funciones y parámetros del software básico.

9. En la etapa 5.1 “Desarrollo de soluciones de diseño para el sistema y sus partes”, aseguran el desarrollo de soluciones generales para el sistema y sus partes, la estructura funcional-algorítmica del sistema, las funciones del personal y la estructura organizacional, la estructura de medios técnicos, algoritmos para la resolución de problemas y lenguajes utilizados, sobre organización y mantenimiento de una base de información, un sistema de clasificación y codificación de información, sobre software.

10. En las etapas 4.2 y 5.2 “Desarrollo de la documentación para la central nuclear y sus partes”, el desarrollo, ejecución, coordinación y aprobación de la documentación se lleva a cabo en la medida necesaria para describir el conjunto completo de decisiones de diseño tomadas y suficiente para el futuro. ejecución de los trabajos de creación de la central nuclear. Tipos de documentos: según GOST 34.201.

11. En la etapa 5.3 “Desarrollo y ejecución de la documentación para el suministro de productos para la finalización de las centrales nucleares y (o) requisitos técnicos (especificaciones técnicas) para su desarrollo”, se lleva a cabo la preparación y ejecución de la documentación para el suministro de productos para la finalización de las centrales nucleares. ; determinación de requisitos técnicos y elaboración de especificaciones técnicas para el desarrollo de productos que no se produzcan en masa.

12. En la etapa 5.4 “Desarrollo de tareas de diseño en partes adyacentes del proyecto de automatización”, desarrollan, formalizan, coordinan y aprueban tareas de diseño en partes adyacentes del proyecto del objeto de automatización para la realización de trabajos constructivos, eléctricos, sanitarios y otros trabajos preparatorios relacionados. a la creación AC.

13. En la etapa 6.1 “Desarrollo de la documentación de trabajo para el sistema y sus partes”, se desarrolla la documentación de trabajo que contiene toda la información necesaria y suficiente para asegurar la implementación de los trabajos de puesta en funcionamiento de la CN y su funcionamiento, así como para mantener el nivel de características operativas (calidad) del sistema de acuerdo con las decisiones de diseño adoptadas, su ejecución, coordinación y aprobación. Tipos de documentos: según GOST 34.201.

14. En la etapa 6.2 "Desarrollo o adaptación de programas", se desarrollan programas y software del sistema, se selecciona, adapta y (o) vincula el software comprado y se desarrolla la documentación del programa de acuerdo con GOST 19.101.

15. En la etapa 7.1 “Preparación del objeto de automatización para la puesta en funcionamiento de la planta”, se trabaja en la preparación organizativa del objeto de automatización para la puesta en funcionamiento de la planta, incluyendo: implementación de soluciones de diseño para la estructura organizativa de la planta; proporcionar a los departamentos del centro de gestión materiales didácticos y metodológicos; Implementación de clasificadores de información.

16. En la etapa 7.2 “Capacitación del personal”, se capacita al personal y se verifica su capacidad para garantizar el funcionamiento de la planta.

17. En la etapa “Completar los altavoces con los productos suministrados”, aseguran la recepción de componentes, materiales y productos de instalación de producción en serie e individuales. Se lleva a cabo el control de calidad entrante.

18. En la etapa 7.4 “Trabajos de construcción e instalación” se realizan los siguientes trabajos: trabajos de construcción de edificios (locales) especializados para alojar el equipo técnico y el personal de la central nuclear; construcción de canales de cable; realizar trabajos de instalación de equipos técnicos y líneas de comunicación; prueba de equipos técnicos instalados; Entrega de equipo técnico para su puesta en servicio.

19. En la etapa 7.5 “Puesta en servicio”, realizan el ajuste autónomo del hardware y software, cargando información en la base de datos y verificando el sistema para su mantenimiento; Configuración integral de todas las herramientas del sistema.

20. En la etapa 7.6 “Realización de pruebas preliminares” se lleva a cabo lo siguiente:

• probar los altavoces para determinar su operatividad y cumplimiento de las especificaciones técnicas de acuerdo con el programa y la metodología de pruebas preliminares;
• solucionar problemas y realizar cambios en la documentación de la central nuclear, incluida la documentación operativa de acuerdo con el informe de prueba;
• emisión del certificado de aceptación de la central nuclear para su operación de prueba.

21. En la etapa 7.7 “Realización de la operación de prueba”, se lleva a cabo la operación de prueba de la central nuclear; análisis de los resultados de la operación de prueba de la central nuclear; modificación (si es necesario) del software AS; ajuste adicional (si es necesario) del equipamiento técnico de la central nuclear; ejecución de un certificado de finalización de la operación de prueba.

22. En la etapa 7.8 “Realización de pruebas de aceptación” se lleva a cabo lo siguiente:

• pruebas de cumplimiento de especificaciones técnicas de acuerdo con el programa y la metodología de pruebas de aceptación;
• análisis de los resultados de las pruebas de AS y eliminación de deficiencias identificadas durante las pruebas;
• ejecución de un acto de aceptación de la central nuclear para operación permanente.

23. En la etapa 8.1 “Realización del trabajo de acuerdo con las obligaciones de garantía”, se trabaja para eliminar las deficiencias identificadas durante la operación de la CN durante los períodos de garantía establecidos y realizar los cambios necesarios en la documentación de la CN.

24. En la etapa 8.2 “Servicio posgarantía” se trabaja en:

• análisis del funcionamiento del sistema;
• identificar las desviaciones de las características operativas reales de la central nuclear respecto de los valores de diseño;
• establecer las causas de estas desviaciones;
• eliminar las deficiencias identificadas y garantizar la estabilidad de las características operativas de la central nuclear;
• realizando los cambios necesarios en la documentación de los ponentes.

APÉNDICE 2. Referencia

LISTA DE ORGANIZACIONES QUE PARTICIPAN EN LA CREACIÓN DE LA UA

1. La organización cliente (usuario) para la cual se creará la central nuclear y que proporciona financiamiento, aceptación de las obras y operación de la central nuclear, así como la ejecución de trabajos individuales para la creación de la central nuclear.

2. Una organización de desarrollo que realiza trabajos de creación de un AS, brindando al cliente un conjunto de servicios científicos y técnicos en las distintas etapas y etapas de creación, así como desarrollando y suministrando diversos software y hardware para el AS.

3. Una organización proveedora que fabrica y suministra software y hardware por encargo del desarrollador o cliente.

4. Organización-diseñador general de la instalación de automatización.

5. Organizaciones de diseño de diversas partes del proyecto de instalación de automatización para la realización de trabajos constructivos, eléctricos, sanitarios y otros trabajos preparatorios relacionados con la creación de la central nuclear.

6. Construcción, instalación, puesta en servicio y otras organizaciones.

Notas:

1. Dependiendo de las condiciones para la creación de la central nuclear, son posibles diversas combinaciones de funciones del cliente, desarrollador, proveedor y otras organizaciones involucradas en la creación de la central nuclear.

2. Con base en esta norma se determinan las etapas y fases del trabajo que realizan para crear el AS.

DATOS DE INFORMACIÓN

1. DESARROLLADO E INTRODUCIDO por el Comité Estatal de Normas y Gestión de la Calidad de los Productos de la URSS

DESARROLLADORES

Yu.H. Vermishev, Doctor en Ingeniería. ciencias; Ya.G. Vilenchik; Y EN. Voropaev, Doctor en Ingeniería. ciencias; L. M. Seidenberg, Ph.D. tecnología. ciencias; Yu.B. Irz, Ph.D. tecnología. ciencias; ENFERMEDAD VENÉREA. Kostyukov, Ph.D. tecnología. ciencias; MAMÁ. Labutín, cond. tecnología. ciencias; NOTARIO PÚBLICO. Leskovskaya; ES. Mitiaev; V.F. Popov (líder del tema); SV Garshina; AI. Sordera; SUR. Zhukov, Ph.D. ciencias; Z.P. Zadubovskaya; V.G. Ivánov; Yu.I. Karavanov, Ph.D. ciencias; AUTOMÓVIL CLUB BRITÁNICO. Klochkov; V.Yu. Korolev; Y EN. Makhnach, Ph.D. tecnología. ciencias; SB Mikhalev, Doctor en Ingeniería. ciencias; V.N. Petrikevich; VIRGINIA. Rakhmanov, Ph.D. economía. ciencias; AUTOMÓVIL CLUB BRITÁNICO. Ratkóvich; R.S. Sedegov, Doctor en Economía. ciencias; NEVADA. Stepanchikova; EM. Surovets; AV. Flegentov; L.O. Khvilevsky, Ph.D. tecnología. ciencias; VC. Chistov, Ph.D. economía. ciencias

2. APROBADO Y ENTRADO EN VIGOR por Resolución del Comité Estatal de Normas y Gestión de Calidad de los Productos de la URSS de 29 de diciembre de 1990 No. 3469

M. Ostrogorski, 2008

Para aplicar con éxito GOST 34, es necesario comprender cómo, desde el punto de vista de este conjunto de estándares, está estructurado el sistema automatizado. De lo contrario, no veremos nada en el invitado excepto una larga lista de documentos con nombres misteriosos, y los requisitos para su contenido nos convencerán una vez más de que en muchas sabidurías hay mucha tristeza. Por tanto, antes de hablar de los documentos en sí, debemos entender cuál es el tema de la documentación.

Sistema automatizado, sus funciones y tareas.

Definición de un sistema automatizado

GOST 34.003-90 contiene la siguiente definición de sistema automatizado: un sistema que consta de personal y un conjunto de herramientas de automatización para sus actividades, que implementa tecnología de la información para realizar funciones establecidas. ¿Qué significa realmente esta definición? Esto sólo se puede entender leyendo otras definiciones de este estándar y comparándolas entre sí. ¿Qué vamos a hacer ahora?

Objetivos de actividad

Un sistema automatizado sólo puede existir cuando hay personal dedicado a una actividad específica. Normalmente, hablamos de actividades cuyos resultados son útiles para alguien, independientemente de las herramientas utilizadas. Por ejemplo, voy a la taquilla del teatro a comprar una entrada y me alegro mucho si el cajero me la escribe con bolígrafo en un formulario, siempre y cuando me dejen entrar al cine usándola. Al cajero, en general, tampoco le importa cómo se hace exactamente el billete. Ella estará bien con cualquier método siempre y cuando no sea demasiado laborioso y le brinde la oportunidad de venderme un boleto. En otras palabras, ella y yo tenemos un objetivo común. GOST 34.003-90 usa el término para denotarlo propósito de la actividad. Cada vez que otro espectador sale de la ventana con una entrada en la mano, y el teatro se enriquece un poco, se consigue este objetivo de la actividad.

Funciones del sistema automatizado.

Puede haber (y, por regla general, hay) varios objetivos para una actividad. Cualquier resultado útil fuera de la propia actividad puede considerarse su objetivo. Entonces, si la cajera no solo vende boletos, sino que también prepara un informe de ventas para sus superiores al final de la jornada laboral, la elaboración de un informe diario puede considerarse como otro objetivo de la actividad.

Si ponemos una computadora y una impresora en el escritorio de la cajera, y el jefe de la cajera le da una orden para que escriba boletos e informes en un procesador de textos y los imprima en la impresora, entonces obtendremos un sistema automatizado. Según las ideas modernas, es muy primitivo; formalmente satisfará la definición de Gost. Tenga en cuenta que los objetivos de la actividad no han cambiado como resultado de la implementación del sistema automatizado, solo ha cambiado el método para lograrlos. Lo que antes se hacía “así”, ahora se hace en el marco de un sistema automatizado. El conjunto de acciones de un sistema automatizado destinadas a lograr un objetivo específico, según GOST 34.003-90, se denomina función. Nota: se mire como se mire, el personal se considera parte del sistema.

La función de un sistema automatizado es un concepto fundamental en GOST 34. Un sistema automatizado se considera, en primer lugar, como la suma de sus funciones y sólo después como un conjunto de "software" y "hardware". Lo más importante es lo que hace el sistema, y ​​en qué consiste es secundario.

Lo anterior podría llevar al lector a la conclusión de que cada objetivo de actividad en un sistema automatizado corresponde a una y sólo una función. Un sistema así es fácil de imaginar, pero la práctica es más variada. Por un lado, las actividades no siempre están completamente automatizadas. Incluso después de la implementación de un sistema automatizado, algunos objetivos deben alcanzarse manualmente. Por otro lado, dado que el mismo resultado en diferentes condiciones se puede lograr de diferentes maneras, varias funciones pueden dirigirse a un objetivo de actividad en un sistema automatizado, por ejemplo, vender una entrada en taquilla y vender una entrada en el Internet. Además, cualquier sistema automatizado requiere cierto mantenimiento, por lo que tenemos que introducir el concepto de función auxiliar. Un ejemplo típico es la creación de una copia de seguridad de los datos.

Tareas del sistema automatizado.

En el caso general, al realizar una función, parte del trabajo lo realiza el personal y parte la tecnología; digamos, un boleto se imprime automáticamente y el cajero lo entrega manualmente al comprador. En GOST 34.003-90 se denomina secuencia de acciones automáticas (sic) que conducen a un resultado de un tipo determinado. tarea.

Aquí la definición del problema no se cita con toda precisión, pero por ahora esto será suficiente para nosotros; después de todo, no es una pena que nadie lea la norma por su cuenta. Es importante que una tarea sea la parte más claramente formalizada de una actividad automatizada. Puedes imaginar una función que se realiza de forma completamente automática, como la copia de seguridad mencionada anteriormente. En este caso, la función se reduce a una sola tarea.

La misma tarea se puede resolver realizando diferentes funciones. Por ejemplo, si un sistema automatizado tiene varias funciones para vender un boleto, entonces la ejecución de cada una de ellas puede requerir en algún momento que se imprima el boleto.

Composición del sistema automatizado.

Subsistemas

Si el sistema automatizado es bastante complejo, se divide en subsistemas. Qué significa, bastante complejo, es bastante difícil de decir. La teoría de sistemas describe diferentes niveles y criterios de complejidad. En la práctica, la necesidad de asignar varios subsistemas en un sistema automatizado a menudo se debe a razones organizativas y financieras; por ejemplo, los subsistemas se desarrollan y ponen en funcionamiento de forma secuencial.

Aunque en GOST 34 el término subsistema se utiliza muchas veces, parece que allí no existe una definición formal de este concepto. La experiencia sugiere que un subsistema es parte de un sistema automatizado que también satisface la definición de sistema automatizado, en particular, tiene funciones completas.

Volviendo al ejemplo de emisión de billetes, podemos decidir que el sistema automatizado consta de dos subsistemas: un subsistema de emisión de billetes y un subsistema de informes diarios. Simplemente acordemos, para mayor claridad, que el cajero escriba los boletos en un editor de texto y los informes en hojas de cálculo.

Componentes

La identificación de los objetivos de la actividad, las funciones de un sistema automatizado y, si es necesario, sus subsistemas es en gran medida subjetiva y depende del punto de vista del sujeto que decidió hacerlo. Si algún resultado es importante en el contexto del problema que se está resolviendo, podemos considerarlo una meta; de lo contrario, ignorarlo. También dividiremos el sistema automatizado en subsistemas de la forma que nos convenga, siempre que nuestras decisiones no contradigan el contenido de este concepto.

Los componentes son las partes a partir de las cuales, en la realidad objetiva, construimos un sistema automatizado. El sistema consta físicamente de sus componentes, por lo que dividir un sistema automatizado en componentes es lo más objetivo.

Compramos cada componente, lo instalamos y conectamos (si es un equipo), lo instalamos (si es un programa) y lo mantenemos por separado de otros componentes. Compramos y colocamos una computadora sobre la mesa: es un componente. Desarrollamos un editor de texto especial para escribir tickets, otro componente. Descargué hojas de cálculo gratuitas de Internet, nuevamente un componente. E incluso la propia cajera, de alguna manera, también es un componente del sistema automatizado.

La composición de los componentes de un sistema automatizado es muy importante desde el punto de vista de su documentación, ya que la documentación técnica del sistema como tal y de los componentes se maneja de forma diferente. Por lo general, debe ser desarrollado por diferentes personas y está diseñado con diferentes estándares según el tipo de componente.

Tipos de garantía

Uno de los conceptos más difíciles para un usuario novato de GOST 34 es tipo de seguridad. ¿Qué tipo de seguridad es esta? ¿Puedes verlo o tocarlo? ¿Vender o comprar?

Cada tipo de software combina componentes o soluciones técnicas de una determinada naturaleza. GOST 34 menciona muchos tipos diferentes de seguridad, aquí no describiremos secuencialmente cada uno de ellos, sino que enumeraremos solo los más notables:

• soporte de información: todos los datos y metadatos con los que funciona el sistema;
• software: todos los programas que forman parte del sistema;
• soporte técnico: todos los medios técnicos (en otras palabras, equipos, equipos) que forman parte del sistema.

Repitamos una vez más, estos no son todos los tipos de seguridad. Ni siquiera podemos decir con certeza que sean los más importantes. Por ejemplo, el soporte metrológico es de gran importancia para los sistemas automatizados de control de procesos (APCS). Muchos sistemas automatizados requieren un soporte matemático y lingüístico complejo. Pero es difícil imaginar un sistema automatizado que carezca por completo de uno de los tres tipos de soporte enumerados anteriormente (ejercicio: pruébelo).