{"id":41257,"date":"2020-02-06T20:43:44","date_gmt":"2020-02-06T17:43:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya"},"modified":"2020-02-06T20:43:44","modified_gmt":"2020-02-06T17:43:44","slug":"avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya","title":{"rendered":"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Continuando con el tema <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/466215\/\">\u00ab\u00bfCu\u00e1les son tus pruebas?\u00bb<\/a><\/noindex>, examinemos el problema del modelado matem\u00e1tico desde una perspectiva diferente. Despu\u00e9s de asegurarnos de que el modelo es fiel a la verdad de la vida, podemos responder a la pregunta principal: \u00ab\u00bfqu\u00e9 es lo que realmente tenemos aqu\u00ed?\u00bb. Al crear un modelo de un objeto t\u00e9cnico, generalmente queremos asegurarnos de que este objeto cumpla con nuestras expectativas. Para esto se realizan c\u00e1lculos din\u00e1micos de los procesos y el resultado se compara con los requisitos. Esto es lo que se conoce como gemelo digital, prototipo virtual y dem\u00e1s t\u00e9rminos modernos que, en la fase de dise\u00f1o, tienen la tarea de garantizar que obtengamos lo que planeamos.<\/p>\n<p><\/p>\n<p>\u00bfC\u00f3mo podemos asegurarnos r\u00e1pidamente de que nuestro sistema es exactamente lo que estamos dise\u00f1ando, si volar\u00e1 o flotar\u00e1 nuestra construcci\u00f3n? \u00bfY si vuela, cu\u00e1n alto? \u00bfY si flota, cu\u00e1n profundo?<\/p>\n<p>\n<img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/e26c4b7db4ee148c73586124dacb6025.jpg\" style=\"display:block;margin: 0 auto;\" \/><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>En este art\u00edculo se analiza la automatizaci\u00f3n de la verificaci\u00f3n del cumplimiento de los requisitos t\u00e9cnicos al crear modelos din\u00e1micos de sistemas t\u00e9cnicos. Como ejemplo, examinaremos un elemento del pliego de condiciones para un sistema de refrigeraci\u00f3n por aire de una aeronave.<\/p>\n<p><\/p>\n<p>Consideramos aquellos requisitos que pueden expresarse num\u00e9ricamente y verificarse matem\u00e1ticamente en base a un modelo de c\u00e1lculo espec\u00edfico. Est\u00e1 claro que esto es solo una parte de los requisitos generales para cualquier sistema t\u00e9cnico, pero es precisamente en su verificaci\u00f3n donde invertimos tiempo, nervios y dinero en la creaci\u00f3n de modelos din\u00e1micos del objeto.<\/p>\n<p><\/p>\n<p>Al describir los requisitos t\u00e9cnicos en forma de documento, se pueden distinguir varios tipos de requisitos diferentes, cada uno de los cuales requiere diferentes enfoques para la formaci\u00f3n de la verificaci\u00f3n autom\u00e1tica del cumplimiento de los requisitos.<\/p>\n<p><\/p>\n<p>Por ejemplo, consideremos este peque\u00f1o pero real conjunto de requisitos:<\/p>\n<p>\n<i><\/p>\n<ol>\n<li> Temperatura del aire atmosf\u00e9rico a la entrada del SVO:<br \/>\nen reposo \u2212 de menos 35 a 35 \u00baC,<br \/>\nen vuelo \u2212 de menos 35 a 39 \u00baC.<\/li>\n<li> Presi\u00f3n est\u00e1tica del aire atmosf\u00e9rico en vuelo \u2212 de 700 a 1013 hPa (de 526 a 760 mm Hg).<\/li>\n<li> Presi\u00f3n total del aire a la entrada del tomador de aire del SVO en vuelo \u2212 de 754 a 1200 hPa (de 566 a 1050 mm Hg).<\/li>\n<li> Temperatura del aire de enfriamiento:<br \/>\nen reposo \u2212 no m\u00e1s de 27 \u00baC, para bloques t\u00e9cnicos \u2212 no m\u00e1s de 29 \u00baC,<br \/>\nen vuelo \u2212 no m\u00e1s de 25 \u00baC, para bloques t\u00e9cnicos \u2212 no m\u00e1s de 27 \u00baC.<\/li>\n<li> Consumo de aire de refrigeraci\u00f3n:<br \/>\nen tierra \u2212 no menos de 708 kg\/h,<br \/>\nen vuelo \u2212 no menos de 660 kg\/h.<\/li>\n<li> La temperatura del aire en los compartimentos de instrumentos \u2212 no m\u00e1s de 60 \u00baC.<\/li>\n<li> La cantidad de humedad libre en el aire de refrigeraci\u00f3n \u2212 no m\u00e1s de 2 g\/kg de aire seco.<\/li>\n<\/ol>\n<p> <\/i><\/p>\n<p>Incluso en este conjunto limitado de requisitos se pueden destacar al menos dos categor\u00edas que deben ser tratadas de manera diferente en el sistema:<\/p>\n<p><\/p>\n<ul>\n<li> requisitos de las condiciones de operaci\u00f3n del sistema (p.p. 1-3);<\/li>\n<li> requisitos param\u00e9tricos del sistema (p.p. 3-7).<\/li>\n<\/ul>\n<p><\/p>\n<p><i>Requisitos de las condiciones de operaci\u00f3n del sistema<\/i><br \/>\nLas condiciones externas para el sistema en desarrollo durante la modelaci\u00f3n pueden ser establecidas como condiciones l\u00edmite, o como resultado del funcionamiento del sistema general.<br \/>\nEn la modelaci\u00f3n din\u00e1mica, es necesario asegurarse de que los modos de operaci\u00f3n establecidos sean cubiertos por el proceso de modelaci\u00f3n.<\/p>\n<p><\/p>\n<p><i>Requisitos param\u00e9tricos del sistema <\/i><br \/>\nEstos requisitos son par\u00e1metros proporcionados por el propio sistema. Durante el proceso de modelaci\u00f3n, podemos obtener estos par\u00e1metros como resultados de los c\u00e1lculos y asegurarnos de que los requisitos se cumplen en cada c\u00e1lculo espec\u00edfico.<\/p>\n<p><\/p>\n<h3>Identificaci\u00f3n y codificaci\u00f3n de requisitos<\/h3>\n<p><\/p>\n<p>Para facilitar el trabajo con los requisitos, las normas existentes recomiendan asignar un identificador a cada requisito. Al asignar identificadores, es muy deseable utilizar un sistema de codificaci\u00f3n uniforme. <\/p>\n<p><\/p>\n<p>El c\u00f3digo del requisito puede ser simplemente un n\u00famero que refleja el n\u00famero de orden del requisito, o puede incluir el c\u00f3digo del tipo de requisito, el c\u00f3digo del sistema o equipo al que se aplica, el c\u00f3digo del par\u00e1metro, el c\u00f3digo de la ubicaci\u00f3n y mucho m\u00e1s de lo que pueda imaginar un ingeniero. (una opci\u00f3n de utilizaci\u00f3n de codificaci\u00f3n se puede ver en el art\u00edculo)<\/p>\n<p><\/p>\n<p>En la tabla 1 se presenta un ejemplo simple de codificaci\u00f3n de requisitos.<\/p>\n<p><\/p>\n<ol>\n<li> c\u00f3digo de fuente de requisitos R- requisitos TS; <\/li>\n<li> c\u00f3digo tipo de requisitos E \u2013 requisitos \u2013 par\u00e1metros del entorno externo, o condiciones de operaci\u00f3n<br \/>\n S \u2014 requisitos proporcionados por el sistema;<\/li>\n<li> c\u00f3digo del estado del avi\u00f3n 0 \u2013 cualquiera, G \u2013 en tierra, F \u2013 en vuelo;<\/li>\n<li> c\u00f3digo del tipo de par\u00e1metros f\u00edsicos T \u2013 temperatura, P \u2013 presi\u00f3n, G \u2013 flujo, humedad H;<\/li>\n<li> n\u00famero de orden del requisito.<\/li>\n<\/ol>\n<p><\/p>\n<table>\n<tr>\n<td><b>ID<br \/>\nRequisitos<\/b><\/td>\n<td><b>Descripci\u00f3n<\/b><\/td>\n<td><b>Par\u00e1metro<\/b><\/td>\n<\/tr>\n<tr>\n<td>REGT01<\/td>\n<td>La temperatura del aire atmosf\u00e9rico en la entrada del sistema de refrigeraci\u00f3n: en estacionamiento, desde menos 35\u00baC hasta 35\u00baC.<\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td>REFT01<\/td>\n<td>La temperatura del aire atmosf\u00e9rico en la entrada del sistema de refrigeraci\u00f3n: en vuelo, desde menos 35\u00baC hasta 39\u00baC.<\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>REFP01<\/td>\n<td>La presi\u00f3n est\u00e1tica del aire atmosf\u00e9rico en vuelo var\u00eda entre 700 y 1013 hPa (de 526 a 760 mmHg).<\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>REFP02<\/td>\n<td>La presi\u00f3n total del aire en la entrada del sistema de refrigeraci\u00f3n en vuelo var\u00eda entre 754 y 1200 hPa (de 566 a 1050 mmHg).<\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSGT01<\/td>\n<td>La temperatura del aire de refrigeraci\u00f3n: en estacionamiento, no m\u00e1s de 27\u00baC. <\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSGT02<\/td>\n<td>La temperatura del aire de refrigeraci\u00f3n: en estacionamiento, para bloques t\u00e9cnicos no m\u00e1s de 29\u00baC. <\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSFT01<\/td>\n<td>La temperatura del aire de refrigeraci\u00f3n en vuelo no debe ser superior a 25\u00baC. <\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSFT02<\/td>\n<td>La temperatura del aire de refrigeraci\u00f3n: en vuelo, para bloques t\u00e9cnicos no m\u00e1s de 27\u00baC. <\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSGG01<\/td>\n<td>El flujo de aire de refrigeraci\u00f3n: en estacionamiento, al menos 708 kg\/h.<\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSFG01<\/td>\n<td>El flujo de aire de refrigeraci\u00f3n: en vuelo, al menos 660 kg\/h.<\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RS0T01<\/td>\n<td>La temperatura del aire en los compartimentos de instrumentos no debe superar los 60\u00baC. <\/td>\n<td> <\/td>\n<\/tr>\n<tr>\n<td>RSH01<\/td>\n<td>La cantidad de humedad libre en el aire de refrigeraci\u00f3n no debe ser superior a 2 g\/kg de aire seco.<\/td>\n<td> <\/td>\n<\/tr>\n<\/table>\n<p><\/p>\n<h3>Proyecto del sistema de verificaci\u00f3n de requisitos.<\/h3>\n<p><\/p>\n<p>Para cada requisito calculado hay un algoritmo de evaluaci\u00f3n de la conformidad de los par\u00e1metros calculados con los par\u00e1metros establecidos en el requisito. En general, cualquier sistema de gesti\u00f3n siempre contiene, por defecto, algoritmos de verificaci\u00f3n de requisitos. Incluso cualquier regulador los contiene. Si la temperatura excede el l\u00edmite, se activa el aire acondicionado. As\u00ed, la primera fase de cualquier regulaci\u00f3n es la verificaci\u00f3n de la conformidad de los par\u00e1metros con el requisito.<\/p>\n<p><\/p>\n<p>Y dado que la verificaci\u00f3n es un algoritmo, se pueden utilizar las mismas herramientas y medios que usamos para crear programas de control. Por ejemplo, el entorno SimInTech permite crear paquetes de proyectos que contienen diversas partes del modelo, realizadas como proyectos separados (modelo de objeto, modelo de sistema de control, modelo del entorno, etc.).<\/p>\n<p><\/p>\n<p>El proyecto de verificaci\u00f3n de requisitos en este caso se convierte en un proyecto de algoritmos y se conecta al paquete del modelo. Y en el modo de modelaci\u00f3n din\u00e1mica, realiza el an\u00e1lisis de conformidad con los requisitos del pliego de condiciones.<\/p>\n<p><\/p>\n<p>Un posible ejemplo de dise\u00f1o del proyecto del sistema se presenta en la Figura 1.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/e57fda1fb5b835a6ac961639db2b1749.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 1. Ejemplo de dise\u00f1o del proyecto de verificaci\u00f3n. <\/i><\/p>\n<p><\/p>\n<p>Al igual que para los algoritmos de control, los requisitos se pueden presentar en forma de un conjunto de hojas. Para facilitar el trabajo con algoritmos en entornos de modelado estructural como SimInTech, Simulink, y AmeSim, se utilizan las capacidades de creaci\u00f3n de estructuras jer\u00e1rquicas en forma de submodelos. Esta organizaci\u00f3n permite agrupar diferentes requisitos en conjuntos para simplificar el trabajo con grandes cantidades de requisitos, tal como se hace para los algoritmos de control (ver figura 2).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/726ad4d5df1975131e71fc8a14ce71fe.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 2. Estructura jer\u00e1rquica del modelo de verificaci\u00f3n de requisitos. <\/i><\/p>\n<p><\/p>\n<p>Por ejemplo, en el caso considerado, se han identificado dos grupos: requisitos para el entorno y requisitos directamente relacionados con el sistema. Por lo tanto, se utiliza una estructura de datos de dos niveles: dos grupos, cada uno de los cuales es una hoja del algoritmo.<\/p>\n<p><\/p>\n<p>Para conectar los datos al modelo se utiliza un esquema est\u00e1ndar de formaci\u00f3n de base de datos de se\u00f1ales, en el que se almacenan datos para el intercambio entre las partes del proyecto.<\/p>\n<p><\/p>\n<p>Al crear y probar software, en esta base se colocan las lecturas de los sensores (an\u00e1logos a los sensores reales del sistema), que son utilizados por el sistema de control.<br \/>\n Para el proyecto de pruebas, en esta misma base de datos se pueden guardar cualquier par\u00e1metro calculado en el modelo din\u00e1mico, y as\u00ed ser utilizado para verificar el cumplimiento de los requisitos.<\/p>\n<p>\nEl propio modelo din\u00e1mico en este caso puede ser implementado en cualquier sistema de modelado matem\u00e1tico o incluso en forma de un programa ejecutable. El \u00fanico requisito es la existencia de interfaces de software para emitir datos de modelado al entorno externo.<\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/ac56799b7a022325f72d0639cd85eba2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 3. Conexi\u00f3n del proyecto de verificaci\u00f3n al modelo integral. <\/i><\/p>\n<p><\/p>\n<p>Un ejemplo de una hoja b\u00e1sica de verificaci\u00f3n de requisitos se presenta en la figura 4. Desde el punto de vista del desarrollador, representa un esquema de c\u00e1lculo habitual, en el que se presenta gr\u00e1ficamente el algoritmo de verificaci\u00f3n de requisitos.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/467f3217a65e0b4a1def034ce75c747e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 4. Hoja de verificaci\u00f3n de requisitos. <\/i><\/p>\n<p><\/p>\n<p>Las partes principales de la hoja de verificaci\u00f3n se describen en la figura 5. El algoritmo de verificaci\u00f3n se forma de manera an\u00e1loga a los esquemas de c\u00e1lculo de los algoritmos de control. En la parte derecha se encuentra un bloque de lectura de se\u00f1ales de la base de datos. En este bloque se accede a la base de datos de se\u00f1ales durante la modelaci\u00f3n.<\/p>\n<p><\/p>\n<p>Las se\u00f1ales recibidas se analizan para calcular las condiciones de verificaci\u00f3n de los requisitos. En este caso, se realiza un an\u00e1lisis de altura para determinar la posici\u00f3n del avi\u00f3n (si est\u00e1 en el estacionamiento o en vuelo). Para este prop\u00f3sito, se pueden utilizar otras se\u00f1ales y par\u00e1metros calculados del modelo.<\/p>\n<p><\/p>\n<p>Las condiciones de verificaci\u00f3n y los par\u00e1metros a verificar se env\u00edan a bloques de verificaci\u00f3n est\u00e1ndar, donde se analiza la conformidad de esos par\u00e1metros con los requisitos establecidos. Los resultados se registran en la base de datos de se\u00f1ales de manera que se pueden usar para generar autom\u00e1ticamente una lista de verificaci\u00f3n.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/1aa7778f56190bf51c112e29eab8a13c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 5. Estructura de la hoja de c\u00e1lculo de verificaci\u00f3n de requisitos.<\/i><\/p>\n<p><\/p>\n<p>No es necesario utilizar se\u00f1ales contenidas en la base de datos como par\u00e1metros a verificar, que son gestionados por par\u00e1metros calculados durante el proceso de modelado. No hay nada que impida realizar c\u00e1lculos adicionales en el marco del proyecto de requisitos, as\u00ed como hacemos para calcular las condiciones de verificaci\u00f3n.<\/p>\n<p><\/p>\n<p>Por ejemplo, este requisito:<\/p>\n<p><\/p>\n<p> <i>El n\u00famero de activaciones del sistema de correcci\u00f3n durante el vuelo hacia el objetivo no debe exceder 5, y el tiempo total de funcionamiento del sistema de correcci\u00f3n no debe superar 30 segundos.<\/i><\/p>\n<p><\/p>\n<p>En este caso, se a\u00f1ade un algoritmo contador al esquema de c\u00e1lculo del proyecto de requisitos para contabilizar el n\u00famero de activaciones y el tiempo total de funcionamiento.<\/p>\n<p><\/p>\n<h3>Bloque de verificaci\u00f3n de requisitos est\u00e1ndar.<\/h3>\n<p><\/p>\n<p>Cada bloque de verificaci\u00f3n de requisitos est\u00e1 dise\u00f1ado para calcular el cumplimiento de un tipo espec\u00edfico de requisito. Por ejemplo, en los requisitos del entorno, hay un rango de temperaturas de trabajo del aire ambiente en el estacionamiento y en vuelo. Este bloque debe recibir como par\u00e1metro la temperatura del aire en el modelo y determinar si este par\u00e1metro cubre el rango de temperaturas establecido.\n<\/p>\n<p>El bloque contiene dos puertos de entrada, param y condition.<\/p>\n<p><\/p>\n<p>El primero recibe el par\u00e1metro a verificar. En este caso, \"Temperatura del ambiente exterior\".<\/p>\n<p><\/p>\n<p>Al segundo puerto se le asigna una variable booleana: la condici\u00f3n de cumplimiento de la verificaci\u00f3n.<\/p>\n<p><\/p>\n<p>Si el segundo puerto recibe TRUE (1), el bloque realiza el c\u00e1lculo de la verificaci\u00f3n del requisito.<\/p>\n<p><\/p>\n<p>Si la segunda entrada recibe FALSE (0), las condiciones de verificaci\u00f3n no se cumplen. Esto es necesario para que se puedan tener en cuenta las condiciones de c\u00e1lculo. En nuestro caso, esta entrada se utiliza para activar o desactivar la verificaci\u00f3n seg\u00fan el estado del modelo. Si la aeronave se encuentra en tierra durante la simulaci\u00f3n, no se verifican los requisitos relacionados con el vuelo, y viceversa: si la aeronave est\u00e1 en vuelo, no se verifican los requisitos relacionados con la operaci\u00f3n en tierra.<\/p>\n<p><\/p>\n<p>Esta entrada tambi\u00e9n se puede utilizar al configurar el modelo, por ejemplo, en la etapa inicial del c\u00e1lculo. Cuando el modelo se lleva al estado requerido, los bloques de verificaci\u00f3n se desactivan, pero tan pronto como el sistema alcanza el r\u00e9gimen de operaci\u00f3n deseado, los bloques de verificaci\u00f3n se activan.<\/p>\n<p><\/p>\n<p>Los par\u00e1metros de este bloque se establecen como:<\/p>\n<p><\/p>\n<ul>\n<li>condiciones l\u00edmite: el l\u00edmite superior (UpLimit) y el l\u00edmite inferior (DownLimit) de los rangos que deben ser verificados;<\/li>\n<li> el tiempo de espera requerido del sistema en los rangos l\u00edmite (TimeInterval) en segundos;<\/li>\n<li>el identificador del requisito ReqName;<\/li>\n<li>la permisibilidad de salir del rango Out_range \u2013 una variable boolean que determina si la salida del valor se considera una violaci\u00f3n del requisito.<\/li>\n<\/ul>\n<p><\/p>\n<p>En algunos casos, la salida del valor verificado significa que el sistema tiene un margen y puede operar fuera del rango de trabajo. En otros casos, la salida significa que el sistema no puede mantener los par\u00e1metros establecidos dentro del rango.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/3cd48fd6597d1ee11ecaea9931c3fbbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 6. Bloque de verificaci\u00f3n t\u00edpico del atributo en el diagrama y sus par\u00e1metros.<\/i><\/p>\n<p><\/p>\n<p>Como resultado del c\u00e1lculo de este bloque, se genera la variable Result, que puede tomar los siguientes valores:<\/p>\n<p><\/p>\n<ul>\n<li>0 \u2013 rNone, valor no definido;<\/li>\n<li>1 \u2013 rDone, requisito cumplido;<\/li>\n<li>2 \u2013 rFault, requisito no cumplido.<\/li>\n<\/ul>\n<p><\/p>\n<p>La imagen del bloque contiene:<\/p>\n<p><\/p>\n<ul>\n<li> texto del identificador;<\/li>\n<li> muestras digitales de los par\u00e1metros de los l\u00edmites de medici\u00f3n;<\/li>\n<li> identificaci\u00f3n de color del estado del par\u00e1metro.<\/li>\n<\/ul>\n<p><\/p>\n<p>Dentro del bloque puede haber un esquema de inferencia l\u00f3gica bastante complejo.<\/p>\n<p>Por ejemplo, para verificar el rango operativo de temperatura del bloque mostrado en la figura 6, el esquema interno se presenta en la figura 7.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/9ce085c82417fdbc5230056de37af65a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 7. Esquema interno del bloque de determinaci\u00f3n del rango de temperatura.<\/i><\/p>\n<p><\/p>\n<p>Dentro del bloque, se utilizan las propiedades definidas en los par\u00e1metros del bloque.<br \/>\nAdem\u00e1s del an\u00e1lisis de conformidad de los requisitos, el esquema interno del bloque contiene un gr\u00e1fico necesario para mostrar los resultados de la simulaci\u00f3n. Este gr\u00e1fico puede ser utilizado tanto para la visualizaci\u00f3n durante el c\u00e1lculo como para el an\u00e1lisis de resultados posterior al c\u00e1lculo.<\/p>\n<p><\/p>\n<p>Los resultados del c\u00e1lculo se transmiten a la salida del bloque y se registran simult\u00e1neamente en un archivo de reporte general, que se crea a partir de los resultados de todo el proyecto. (ver figura 8)<\/p>\n<p><\/p>\n<p>El ejemplo de reporte, creado a partir de los resultados de la simulaci\u00f3n, representa un archivo HTML, dise\u00f1ado de acuerdo a un formato espec\u00edfico. El formato puede ser configurado de forma arbitraria para ajustarse al que utiliza una organizaci\u00f3n particular.<\/p>\n<p><\/p>\n<p>Dentro del bloque, se utilizan las propiedades definidas en los par\u00e1metros del bloque.<br \/>\nAdem\u00e1s del an\u00e1lisis de conformidad de los requisitos, el esquema interno del bloque contiene un gr\u00e1fico necesario para mostrar los resultados de la simulaci\u00f3n. Este gr\u00e1fico puede ser utilizado tanto para la visualizaci\u00f3n durante el c\u00e1lculo como para el an\u00e1lisis de resultados posterior al c\u00e1lculo.<\/p>\n<p><\/p>\n<p>Los resultados del c\u00e1lculo se transmiten a la salida del bloque y se registran simult\u00e1neamente en un archivo de reporte general, que se crea a partir de los resultados de todo el proyecto. (ver figura 8)<\/p>\n<p><\/p>\n<p>El ejemplo de reporte, creado a partir de los resultados de la simulaci\u00f3n, representa un archivo HTML, dise\u00f1ado de acuerdo a un formato espec\u00edfico. El formato puede ser configurado de forma arbitraria para ajustarse al que utiliza una organizaci\u00f3n particular.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/8ff948417d799bce621e34c709154116.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 8. Ejemplo de archivo de reporte a partir de los resultados de la simulaci\u00f3n.<\/i><\/p>\n<p><\/p>\n<p>En este ejemplo, la configuraci\u00f3n del formulario del reporte se realiza directamente en las propiedades del proyecto, mientras que el formato en la tabla se establece como se\u00f1ales globales del proyecto. En este caso, SimInTech resuelve la tarea de configuraci\u00f3n del reporte por s\u00ed mismo, y el bloque de registro de resultados en el archivo utiliza estas l\u00edneas para escribir en el archivo de reporte.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/bbe363bf1d81d00aebb67ca29a35811b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 9. Configuraci\u00f3n del formato de reporte en las se\u00f1ales globales del proyecto.<\/i><\/p>\n<p><\/p>\n<h3>Uso de la base de datos de se\u00f1ales para los requisitos.<\/h3>\n<p><\/p>\n<p>Para automatizar el trabajo con la configuraci\u00f3n de propiedades para cada bloque est\u00e1ndar, se crea una estructura tipo en la base de datos de se\u00f1ales. (ver figura 10)<\/p>\n<\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/7e20a24ca5dadd2da6542325e964ec00.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 10. Ejemplo de la estructura del bloque de verificaci\u00f3n de requisitos en la base de datos de se\u00f1ales.<\/i><\/p>\n<p><\/p>\n<p>La base de datos de se\u00f1ales proporciona:<\/p>\n<p><\/p>\n<ul>\n<li> Almacenamiento de todos los par\u00e1metros necesarios para los requisitos del sistema.<\/li>\n<li> Visualizaci\u00f3n conveniente de los requisitos existentes en el proyecto a partir de los par\u00e1metros establecidos y los actuales resultados de simulaci\u00f3n.<\/li>\n<li> Configuraci\u00f3n de un bloque o de un grupo de bloques utilizando un lenguaje de programaci\u00f3n de scripts. Los cambios en la base de datos de se\u00f1ales llevan a cambios en los valores de las propiedades del bloque en el esquema.<\/li>\n<li> Almacenamiento de descripciones textuales, enlaces a secciones del documento de requisitos o identificadores en el sistema de gesti\u00f3n de requisitos.<\/li>\n<\/ul>\n<p><\/p>\n<p>Las estructuras de la base de datos de se\u00f1ales para requisitos pueden ser f\u00e1cilmente configuradas para trabajar con un sistema externo de gesti\u00f3n de requisitos. El esquema general de interacci\u00f3n con los sistemas de gesti\u00f3n de requisitos se presenta en la figura 11.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante la modelizaci\u00f3n din\u00e1mica.\" src=\"\/wp-content\/uploads\/2020\/02\/3f6d67b8160255fd39d0d8bedf8be655.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figura 11. Esquema de interacci\u00f3n con el sistema de gesti\u00f3n de requisitos.<\/i><\/p>\n<p><\/p>\n<p>La secuencia de interacci\u00f3n del proyecto de prueba SimInTech con el sistema de gesti\u00f3n de requisitos es la siguiente:<\/p>\n<p><\/p>\n<ol>\n<li> El pliego de condiciones se descompone en requisitos.<\/li>\n<li> Se destacan aquellos requisitos del pliego de condiciones que pueden ser verificados mediante modelado matem\u00e1tico de procesos t\u00e9cnicos.<\/li>\n<li> Los atributos de los requisitos destacados se transmiten a la base de datos de se\u00f1ales de SimInTech en estructuras de bloques t\u00edpicos (por ejemplo, temperatura m\u00e1xima y m\u00ednima).<\/li>\n<li> Durante el c\u00e1lculo, los datos de las estructuras se env\u00edan a los esquemas de c\u00e1lculo de los bloques, se realiza el an\u00e1lisis y los resultados se guardan en la base de datos de se\u00f1ales.<\/li>\n<li> Al finalizar el c\u00e1lculo, los resultados del an\u00e1lisis se env\u00edan al sistema de gesti\u00f3n de requisitos.<\/li>\n<\/ol>\n<p><\/p>\n<p>Las etapas de trabajo con los requisitos 3 a 5 pueden repetirse durante el proceso de dise\u00f1o, cuando ocurren cambios en el dise\u00f1o y\/o requisitos y, por lo tanto, es necesaria una nueva verificaci\u00f3n del impacto de los cambios introducidos.<\/p>\n<p><\/p>\n<h3>Conclusiones.<\/h3>\n<p><\/p>\n<ul>\n<li> El prototipo del sistema creado garantiza una reducci\u00f3n significativa del tiempo de an\u00e1lisis de los modelos existentes en relaci\u00f3n con el cumplimiento de los requisitos del pliego de condiciones.<\/li>\n<li> La tecnolog\u00eda de prueba propuesta utiliza modelos din\u00e1micos ya existentes y puede ser utilizada incluso para cualquier modelo din\u00e1mico, incluyendo aquellos desarrollados fuera del entorno SimInTech.<\/li>\n<li> El uso de una organizaci\u00f3n de datos por lotes permite crear paquetes de verificaci\u00f3n de requisitos, paralelamente al desarrollo de modelos, o incluso utilizar estos paquetes como pliego de condiciones para el desarrollo de modelos.<\/li>\n<li> La tecnolog\u00eda puede integrarse sin costes significativos con los sistemas de gesti\u00f3n de requisitos existentes.<\/li>\n<\/ul>\n<p><\/p>\n<p>Para aquellos que han llegado hasta el final, <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/be9qPox4AXk\">enlace al video de demostraci\u00f3n del funcionamiento del prototipo.<\/a><\/noindex><\/p>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/486336\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u00ab\u041a\u0430\u043a\u0438\u0435 \u0432\u0430\u0448\u0438 \u0434\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u0430?\u00bb, \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u043d\u0430 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u043c\u0430\u0442\u0435\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u043e\u0440\u043e\u043d\u044b. \u041f\u043e\u0441\u043b\u0435 \u0442\u043e\u0433\u043e \u043a\u0430\u043a \u043c\u044b \u0443\u0431\u0435\u0434\u0438\u043b\u0438\u0441\u044c, \u0447\u0442\u043e \u043c\u043e\u0434\u0435\u043b\u044c \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u0435\u0442 \u0441\u0435\u0440\u043c\u044f\u0436\u043d\u043e\u0439 \u043f\u0440\u0430\u0432\u0434\u0435 \u0436\u0438\u0437\u043d\u0438, \u043c\u043e\u0436\u043d\u043e \u043e\u0442\u0432\u0435\u0447\u0430\u0442\u044c \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0439 \u0432\u043e\u043f\u0440\u043e\u0441: \u00ab\u0430 \u0447\u0442\u043e, \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u043c\u044b \u0442\u0443\u0442 \u0438\u043c\u0435\u0435\u043c?\u00bb. \u0421\u043e\u0437\u0434\u0430\u0432\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043e\u0431\u044a\u0435\u043a\u0442\u0430, \u043c\u044b, \u043a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u0445\u043e\u0442\u0438\u043c \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u044d\u0442\u043e\u0442 \u043e\u0431\u044a\u0435\u043a\u0442 \u0431\u0443\u0434\u0435\u0442 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u043e\u0432\u0430\u0442\u044c \u043d\u0430\u0448\u0438\u043c \u043e\u0436\u0438\u0434\u0430\u043d\u0438\u044f\u043c. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u0438 \u043f\u0440\u043e\u0432\u043e\u0434\u044f\u0442\u0441\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":41258,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-41257","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u00ab\u041a\u0430\u043a\u0438\u0435 \u0432\u0430\u0448\u0438 \u0434\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u0430?\u00bb, \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u043d\u0430 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u043c\u0430\u0442\u0435\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u043e\u0440\u043e\u043d\u044b.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0430 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u0439 \u0422\u0417 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u00ab\u041a\u0430\u043a\u0438\u0435 \u0432\u0430\u0448\u0438 \u0434\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u0430?\u00bb, \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u043d\u0430 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u043c\u0430\u0442\u0435\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u043e\u0440\u043e\u043d\u044b.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-06T17:43:44+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-06T17:43:44+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Verificaci\u00f3n autom\u00e1tica de los requisitos del pliego de condiciones durante el modelado din\u00e1mico | ProHoster","description":"Continuando con el tema \u00ab\u00bfCu\u00e1les son sus pruebas?\u00bb, miraremos el problema del modelado matem\u00e1tico desde otra perspectiva.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0430 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u0439 \u0422\u0417 \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f | ProHoster","og:description":"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u044f \u0442\u0435\u043c\u0443 \u00ab\u041a\u0430\u043a\u0438\u0435 \u0432\u0430\u0448\u0438 \u0434\u043e\u043a\u0430\u0437\u0430\u0442\u0435\u043b\u044c\u0441\u0442\u0432\u0430?\u00bb, \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u043d\u0430 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u043c\u0430\u0442\u0435\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441 \u0434\u0440\u0443\u0433\u043e\u0439 \u0441\u0442\u043e\u0440\u043e\u043d\u044b.","og:url":"https:\/\/prohoster.info\/es\/blog\/avtomaticheskaya-proverka-trebovanij-tz-v-proczesse-dinamicheskogo-modelirovaniya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-06T17:43:44+00:00","article:modified_time":"2020-02-06T17:43:44+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"41257","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:20:47","updated":"2022-10-01 02:07:44","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/41257","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=41257"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/41257\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/41258"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=41257"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=41257"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=41257"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}