Volver a Investigación de mercado
Scortex suministra sistemas de inspección visual automatizada para la fabricación. Sus kits Spark y Spark Multi View combinan cámaras, iluminación, cálculo local y conexión con los equipos de producción para identificar y rechazar piezas no conformes. Quality Center proporciona imágenes de inspección, trazabilidad e informes. Scortex pertenece al grupo TRIGO desde mayo de 2022. (1, 2, 3, 14)
Puntuación global de supply chain: 5,2/10.
| Dimensión | Puntuación |
|---|---|
| Profundidad en supply chain | 4,0/10 |
| Sustancia de las decisiones y la optimización | 5,4/10 |
| Integridad del producto y la arquitectura | 5,4/10 |
| Transparencia técnica | 5,6/10 |
| Seriedad del proveedor | 5,6/10 |
Scortex automatiza una decisión concreta de producción: si una pieza observada cumple un estándar de inspección. Su relevancia para la economía de la supply chain procede del rendimiento, los descartes, las reclamaciones de clientes y el trabajo de inspección. Las compras, la asignación de inventario, la reposición incierta y la planificación de la producción quedan fuera del alcance documentado del producto. Por tanto, la puntuación refleja un producto adyacente con sustancia técnica y un solapamiento limitado con el software de decisiones de supply chain. (2, 3)
La evidencia más sólida combina instalaciones físicas e investigación publicada sobre detección de anomalías. La más débil concierne al punto de funcionamiento económico: cuántas piezas buenas se rechazan, cuántas defectuosas pasan inadvertidas, cómo se comporta el modelo tras cambios de producción y cuánto cuesta mantenerlo. La calculadora pública de ROI de Scortex agrava esta carencia al tratar los costes de calidad introducidos como ahorros íntegramente recuperables e impedir que el resultado mostrado para el primer año sea negativo. (4, 5, 19, 20)
Scortex frente a Lokad
Un fabricante de envases puede usar Scortex para rechazar un recipiente visiblemente defectuoso. La tarea numérica consiste en inferir la conformidad a partir de una imagen y ejecutar una decisión de clasificación. Las preguntas posteriores de supply chain son distintas: cuánto producto utilizable cabe esperar, cuánto material de sustitución pedir y si el siguiente turno de producción debe atender a un cliente u otro. Los registros de inspección de Spark pueden informar esas decisiones, pero su oferta publicada no las calcula. (2, 3)
La optimización de inventario de Lokad aborda decisiones recurrentes de compra, producción y asignación mediante valoración financiera bajo incertidumbre. Los Supply Chain Scientists mantienen la lógica de decisión y su interpretación de los datos empresariales. La relación útil es complementaria: las mediciones de inspección pueden mejorar la representación de rendimientos inciertos, mientras que un modelo de supply chain valora sus consecuencias para materiales, capacidad y servicio al cliente.
La perspectiva económica de Introduction to Supply Chain también se aplica en la estación de inspección. Rechazar más piezas puede reducir las reclamaciones y aumentar al mismo tiempo los descartes y los faltantes de stock. Cuando las especificaciones permiten cierto criterio, el umbral económicamente adecuado depende de esas consecuencias. Si un defecto incumple un requisito obligatorio de seguridad o normativo, ese requisito restringe la decisión; una cifra agregada de «precisión» no puede determinar qué errores son aceptables.
De las imágenes a una decisión de producción
Spark aprende el aspecto normal a partir de piezas conformes y después detecta desviaciones. La página actual del producto describe unas pocas docenas de piezas de entrenamiento, hasta cuatro vistas, ajustes de la variabilidad aceptada y una decisión conjunta de rechazo enviada al PLC de la línea. Esto reduce la necesidad de enumerar todos los defectos posibles antes de la implantación. Sigue exigiendo muestras normales representativas y una definición pertinente de la variación aceptable. (2)
De lo contrario, el modelo puede aprender una distinción equivocada. Una nueva decoración, un reflejo de iluminación diferente o un cambio inocuo de posición pueden parecer anomalías; un defecto recurrente incluido por accidente en el conjunto de referencia puede parecer normal. El resultado económicamente útil depende del muestreo, la presentación, la selección de umbrales y la validación en las condiciones que realmente se repiten en la línea.
La investigación publicada mejora un algoritmo existente
El artículo de Scortex de julio de 2023 estudia PatchCore con los conjuntos públicos MVTec AD y VisA. PatchCore compara características de fragmentos de imagen con una memoria de ejemplos normales. Los investigadores varían el extractor de características, la resolución de entrada, el aumento de datos y el submuestreo del banco de memoria. Su extractor con antialiasing mejora el rendimiento con pocos ejemplos de referencia; el aumento de datos ayuda en ciertas configuraciones y perjudica en otras. El artículo presenta métricas de reconocimiento y segmentación, experimentos repetidos de muestreo y limitaciones por categoría. (5)
El repositorio adjunto publica la implementación y los scripts experimentales, identifica las modificaciones del paquete Anomalib original e indica el hardware de evaluación. Es un trabajo sustancial sobre un método existente, con suficiente información para examinar su aportación. El experimento publicado no especifica todas las versiones de Spark. (6)
Sus métricas también requieren la interpretación correcta. El área bajo una curva ROC mide la discriminación entre umbrales; no especifica la tasa de defectos no detectados de una fábrica con la tasa de rechazo elegida. Un buen resultado de referencia puede coexistir con demasiados falsos rechazos cuando los defectos son infrecuentes. Las pruebas de aceptación necesitan recuentos separados de defectos no detectados y piezas buenas rechazadas, por tipo de defecto y condición operativa, con los costes correspondientes.
El caudal y la latencia son restricciones distintas
La ficha de 2024 especifica hasta tres piezas por segundo para Spark, una para Multi View y 925 milisegundos de latencia del resultado. La revisión de marzo de 2025 sitúa una cifra de tres piezas por segundo sobre ambas columnas de producto y mantiene la latencia. Son especificaciones de versiones concretas; la cifra nueva no debe atribuirse retrospectivamente a estaciones antiguas. (7, 8)
El caudal puede superar el inverso de la latencia cuando las inspecciones se solapan. Aun así, la integración debe conservar la identidad de cada pieza hasta que se active el expulsor. El número de cámaras, la captura, la velocidad de la cinta, la sincronización del disparo y la distancia de expulsión determinan si una estación puede mantener la tasa prometida. El folleto de agosto de 2026 anuncia tres piezas por segundo, pero no aporta resultados de aceptación para cargas concretas. (3)
Historia tecnológica y ejecución
| Periodo | Registro público | Qué demuestra |
|---|---|---|
| 2016–2017 | Notion registra la fundación en 2016 y la inversión inicial en 2017; Alven documenta la ronda semilla de 1,8 millones de euros. | El negocio de inspección industrial precedía a la actual ola de agentes. Su propuesta inicial de IA trataba una tarea de visión acotada. (9, 10) |
| 2019–2021 | Scortex se incorporó a COGNITWIN y aportó inferencia de imágenes sobre FPGA. Un boletín del consorcio de 2021 describe un modelo propio capaz de procesar hasta 100 imágenes por segundo a una resolución de 1920 × 1200. | Un experimento específico de hardware y modelo sustenta el vocabulario del gemelo digital. El boletín aún identifica la evaluación con datos de socios como trabajo futuro. (11, 12) |
| 2022 | TRIGO anunció la adquisición, una intención de invertir 5 millones de euros ese año y planes de ampliar la plantilla. | El comprador aportó un canal de servicios de calidad y un compromiso de financiación; el anuncio no mide el rendimiento posterior de la ingeniería. (14) |
| 2023–2024 | Aparecieron el artículo y el código de detección de anomalías; Toly describió después tres instalaciones Spark y cambios más rápidos. | Hay evidencia tanto de investigación como de producto instalado, con alcances diferentes. (4, 5, 6) |
| 2025–2026 | Las fichas actualizadas y el folleto vigente mantienen la inspección local, el hardware multivista, los datos de calidad y el apoyo experto. | La orientación del producto sigue centrada en visión industrial, en lugar de añadir un asistente general de planificación. (3, 8) |
El anuncio de COGNITWIN utilizaba un lenguaje ambicioso sobre sistemas de procesos autoorganizados y la predicción de acontecimientos indeseables. La contribución de Scortex era más estrecha: acelerar el procesamiento de imágenes en hardware. El informe final describe seis pilotos industriales y sus resultados, sin demostrar que el componente de Scortex produjera esas mejoras. Esos resultados del consorcio no pueden atribuirse a Spark. (11, 13)
Del mismo modo, la afirmación de 100 imágenes por segundo con FPGA mide la inferencia de un modelo, no la inspección completa con posicionamiento, múltiples vistas y rechazo. Las especificaciones públicas actuales no establecen qué configuraciones Spark conservan ese diseño FPGA. La cronología respalda una continuidad real de investigación, pero deja sin resolver la transición del acelerador experimental al hardware comercial. (7, 8, 12)
Productividad, mantenimiento de configuraciones y cambios de producción
La entrevista de Toly de junio de 2024 ofrece el relato más claro de una implantación. Su director técnico indica que hay tres estaciones y que la primera se instaló unos dieciocho meses antes. Cambiar decoraciones lleva minutos o, como máximo, una hora, frente a días con anteriores sistemas de visión. A una velocidad de 50–60 piezas por minuto, detectar antes también limita la cantidad producida antes de corregir el proceso. Son mecanismos concretos para reducir costes de inspección y desperdicio. (4)
La entrevista indica un objetivo de desperdicio inferior al 1% y afirma cualitativamente que los ahorros compensan la inversión. No publica la tasa lograda, los falsos rechazos, los defectos que pasan inadvertidos ni todo el trabajo de apoyo. Importa distinguir un objetivo de un resultado observado: reducir descartes mejorando el proceso de producción es distinto de cambiar simplemente qué piezas rechaza un inspector. (4)
La descripción legal de Scortex exige expresamente colaboración del cliente, documentos, adaptación de equipos y parámetros y ajustes durante las pruebas. El puesto de técnico óptico incluye elegir y probar luces, objetivos, sensores y técnicas de captura. Por tanto, la puesta en marcha física forma parte del trabajo de ingeniería, aunque el uso rutinario del software sea sencillo. (18, 21)
Hay dos preguntas distintas de productividad. Primero, cuánto trabajo de inspección desaparece con la calidad de salida acordada. Segundo, cuánto trabajo exige introducir un producto nuevo o reparar un modelo que falla. Lo segundo incluye seleccionar muestras de referencia, ajustar cámaras, validar umbrales, realizar pruebas de producción y prestar soporte. Más estaciones o una inferencia más rápida no responden por sí solas a ninguna de ellas.
Un ciclo útil de mejora conservaría las imágenes de un rechazo perjudicial, determinaría si el error procede de la óptica, el muestreo, la semántica o los umbrales y volvería a probar el modelo corregido en condiciones antiguas y nuevas. Es el equivalente en inspección de la holimization. Scortex proporciona trazabilidad y reentrenamiento, pero el material público no muestra un caso completo y versionado que vaya del fallo a la corrección con resultados de regresión. (2, 3)
Lista de componentes de software y carga operativa
| Componente o evidencia | Alcance documentado | Consecuencia |
|---|---|---|
| Equipamiento local de inspección | Ordenador de borde, PLC, cámaras, iluminación, pantalla táctil y conectividad 4G/Ethernet en los kits Spark | Sistema operativo, software de dispositivos, sincronización e interfaces de hardware deben trabajar juntos al ritmo de la línea. (8) |
| Herramientas de integración de SparkOS | El repositorio público de compilación LinuxPTP de Scortex produce un contenedor Docker para SparkOS y un paquete para un controlador Wago | La sincronización temporal y el empaquetado de contenedores forman parte concreta del perímetro de ingeniería. (17) |
| Implementación de investigación | Python, código Anomalib modificado, ejecución experimental en GPU | La investigación publicada se puede examinar; no identifica todo el entorno comercial de ejecución. (6) |
| Ingeniería de producción | El puesto de ingeniero de plataforma de 2026 abarca pipelines de despliegue, infraestructura física y virtual, bases de datos, monitorización y optimización de costes facturados | Mantener la inferencia entre fábricas requiere trabajo continuo de software y operaciones. (16) |
La oferta de empleo enumera muchas herramientas de ejemplo como experiencia deseada. No demuestra que todas se ejecuten juntas dentro de Spark. Las bases de datos, colas, orquestación y servicios cloud del producto real siguen poco documentados. No obstante, su coste operativo material es visible: despliegue de modelos, conservación de imágenes, flotas de dispositivos, mantenimiento físico y soporte remoto necesitan responsables. (16)
El cálculo local mantiene la clasificación inmediata en la estación. Los informes cloud añaden un ciclo de vida separado para imágenes almacenadas, acceso, sincronización y recuperación. La documentación pública no cuantifica volúmenes de conservación, cuotas recurrentes, interrupciones por actualizaciones ni el trabajo necesario para mantener la calidad de inspección cuando cambian las referencias de producto. (3, 8, 18)
Seguridad y control de producción
El artículo de seguridad de Scortex afirma que el producto de borde y la infraestructura cloud obtuvieron la máxima calificación en pruebas de seguridad. No identifica el modelo de amenazas, la versión probada, los límites de privilegios, la firma de actualizaciones, los controles de acceso remoto ni el procedimiento de recuperación. Esa garantía ofrece poca base para evaluar qué ocurre si se compromete una cuenta, un dispositivo o una actualización. (15)
La arquitectura contiene una frontera importante entre un sistema de inspección conectado a la red y equipos que rechazan productos físicos. Un despliegue seguro debe limitar quién puede cambiar el modelo activo, modificar umbrales, enviar órdenes a dispositivos o exportar datos de inspección. También debe definir un comportamiento seguro cuando fallen las comunicaciones, la inferencia o el seguimiento de piezas. Las interfaces de hardware publicadas identifican la conexión; no demuestran esas salvaguardas. (8, 17)
Las imágenes y los registros pueden ayudar a reconstruir un incidente. Su valor depende de que los cambios de modelos, umbrales y registros sigan siendo atribuibles y recuperables tras una intrusión. Los documentos públicos no describen versiones inmutables de modelos, historiales resistentes a manipulaciones, reversión probada ni políticas de parches para toda la flota. (3, 15)
La calculadora de ROI presupone las ganancias que debería demostrar
La calculadora pública acepta dotación de inspección, volumen anual de piezas, tasa de descarte, número de reclamaciones y coste por reclamación. Con los valores predeterminados muestra 66.000 € y unos cuatro meses de amortización. La afirmación adjunta sobre la media de clientes es de diez meses, sin cohorte ni método de cálculo publicados. (19)
El código de cálculo utiliza 35.000 € por operario-año, 1 € por pieza descartada y un coste de Spark de 29.000 €. Suma todos los costes introducidos de personal, descartes y reclamaciones como ahorros anuales. Con los valores predeterminados da 95.000 € antes de restar el supuesto del equipo, de ahí los 66.000 €. No hay factores de reducción por personal que permanece, descartes restantes o reclamaciones que siguen ocurriendo, ni un término de mantenimiento recurrente. El importe mostrado también se limita a cero si el cálculo del primer año es negativo. Son supuestos de la calculadora, no una oferta comercial verificada. (20)
Es una carencia sustancial de responsabilidad económica. La inspección no puede recuperar todo el descarte de fabricación simplemente detectando defectos; parte de su beneficio puede proceder de posteriores correcciones del proceso. Reasignar operarios tampoco genera necesariamente un ahorro equivalente de caja. Un modelo económico útil debe exponer estas diferencias y admitir pérdidas, incluidos los costes de falsos rechazos, defectos no detectados, implantación, mantenimiento e interrupciones.
El aviso legal público exige un acuerdo separado con el cliente y describe una puesta en marcha colaborativa. No especifica una garantía económica, tasas de aceptación de errores de clasificación ni responsabilidad por una amortización fallida. Esos compromisos deben establecerse independientemente de la calculadora. (18)
Puntuación de supply chain
Profundidad en supply chain
| Criterio | Puntuación |
|---|---|
| Enfoque económico | 4/10 |
| Decisión como resultado final | 2/10 |
| Claridad conceptual sobre supply chain | 3/10 |
| Independencia de doctrinas centrales obsoletas | 7/10 |
| Resistencia al teatro de los KPI | 4/10 |
Media: 4,0/10.
Enfoque económico. Los costes de inspección y las pérdidas de calidad son preocupaciones comerciales explícitas. La calculadora presupone recuperar costes sin establecer reducciones alcanzables, mientras que el producto no optimiza las consecuencias monetarias más amplias del rendimiento y los faltantes. (19, 20)
Decisión como resultado final. Spark ejecuta una decisión de conformidad en la línea. No aporta decisiones de compras, inventario, programación o asignación, lo que limita su solapamiento competitivo con la optimización de supply chain. (2)
Claridad conceptual sobre supply chain. El producto aborda una fuente relevante de incertidumbre productiva. Los materiales públicos no llegan a propagar las observaciones de calidad hacia previsiones de producción utilizable y decisiones sobre recursos en toda la supply chain. (3)
Independencia de doctrinas centrales obsoletas. El modelo operativo automatiza una inspección física repetida, en vez de crear una reunión S&OP o una previsión consensuada. Su alcance acotado deja la doctrina general de planificación fuera del producto. (2, 4)
Resistencia al teatro de los KPI. La investigación identifica métricas significativas de reconocimiento y sus limitaciones. Las afirmaciones comerciales de cobertura, caudal y amortización carecen de las mediciones completas de errores y costes necesarias para evaluar un despliegue industrial. (5, 8, 19)
Sustancia de las decisiones y la optimización
| Criterio | Puntuación |
|---|---|
| Profundidad de la modelización probabilística | 2/10 |
| Sustancia distintiva en optimización o ML | 7/10 |
| Gestión de restricciones reales | 6/10 |
| Automatización de decisiones y productividad laboral | 7/10 |
| Resiliencia ante la complejidad operativa real | 5/10 |
Media: 5,4/10.
Profundidad de la modelización probabilística. La puntuación de anomalía concierne a la pieza observada. La oferta no documenta una previsión calibrada de rendimientos, fallos o estados futuros de suministro utilizada para optimizar acciones posteriores. (2, 5)
Sustancia distintiva en optimización o ML. Los experimentos y el código publicados demuestran una mejora concreta de un método establecido de detección de anomalías. La selección comercial de modelos, su calibración y el rendimiento por versión están menos expuestos que la implementación de investigación. (5, 6)
Gestión de restricciones reales. La captura multivista y una interfaz PLC documentada abordan la presentación física y la integración en línea. Una implantación satisfactoria sigue dependiendo de la óptica, la sincronización y la identidad de las piezas en las condiciones reales del cliente. (8, 21)
Automatización de decisiones y productividad laboral. La estación puede clasificar y rechazar sin que una persona examine cada imagen. El relato de Toly respalda una configuración y una respuesta del proceso más rápidas; la evidencia publicada no cuantifica todo el personal y soporte restantes con un estándar fijo de calidad de salida. (2, 4)
Resiliencia ante la complejidad operativa real. La trazabilidad y el reentrenamiento facilitan corregir cambios de producción. Falta una secuencia documentada desde un error costoso, pasando por datos de referencia o criterios revisados, hasta un despliegue probado mediante regresión. (3, 16)
Integridad del producto y la arquitectura
| Criterio | Puntuación |
|---|---|
| Coherencia arquitectónica | 7/10 |
| Claridad de los límites del sistema | 7/10 |
| Seriedad en seguridad | 3/10 |
| Parsimonia de software y coste de propiedad | 5/10 |
| Compatibilidad con operaciones programáticas y asistidas por agentes | 5/10 |
Media: 5,4/10.
Coherencia arquitectónica. La detección y clasificación locales, el control de equipos y el análisis remoto de calidad forman un producto coherente. El inventario comercial de software y la arquitectura de publicación de modelos siguen documentados solo en parte. (3, 8, 16)
Claridad de los límites del sistema. Las fichas identifican la interfaz de control físico y el recorrido local de decisión. La integración necesita especificaciones públicas más precisas de estados de fallo, intercambio externo de datos y responsabilidades entre la estación de inspección y los equipos productivos. (7, 8)
Seriedad en seguridad. El artículo de seguridad afirma el éxito de las pruebas sin exponer controles que limiten las consecuencias de una estación, cuenta o actualización comprometida. La autorización de modelos, los privilegios de comandos, la integridad de eventos y el despliegue recuperable necesitan mecanismos concretos. (15, 17)
Parsimonia de software y coste de propiedad. Un kit de inspección centrado evita una suite de planificación desmesurada. Su hardware, óptica, gestión de flotas y validación específica por cliente siguen siendo costes materiales; ninguna explicación pública del TCO reconcilia esos costes con la amortización anunciada. (16, 18, 21)
Compatibilidad con operaciones programáticas y asistidas por agentes. Se documentan el control automático de máquinas y los pipelines de despliegue de ingeniería. Son mucho menos visibles las herramientas públicas para probar, aprobar, desplegar y revertir programáticamente modelos de inspección de clientes. (8, 16, 17)
Transparencia técnica
| Criterio | Puntuación |
|---|---|
| Documentación técnica pública | 6/10 |
| Inspección sin mediación del proveedor | 6/10 |
| Visibilidad de portabilidad y dependencia | 4/10 |
| Transparencia del método de implantación | 6/10 |
| Densidad de evidencia tras las afirmaciones técnicas | 6/10 |
Media: 5,6/10.
Documentación técnica pública. Las fichas, un artículo de investigación y el código exponen mecanismos reales. Los manuales públicos de administración, integración, seguridad y gobierno de modelos son mucho más escasos. (5, 6, 8, 15)
Inspección sin mediación del proveedor. La implementación de investigación puede estudiarse independientemente. Evaluar la sensibilidad, el ciclo de vida del modelo y el comportamiento ante fallos de la estación comercial real requiere participación del proveedor. (6, 18)
Visibilidad de portabilidad y dependencia. Las interfaces físicas proporcionan una frontera de integración, pero los materiales públicos no establecen modelos entrenados exportables, configuraciones portátiles ni un entorno de ejecución independiente para sustituir Scortex. (8, 18)
Transparencia del método de implantación. Las ofertas del empleador y el relato de despliegue explican por qué importan las pruebas ópticas, la configuración y el soporte continuo. Los procedimientos de aceptación y costes recurrentes de cambio quedan poco especificados. (4, 16, 21)
Densidad de evidencia tras las afirmaciones técnicas. Experimentos concretos y límites de hardware por versión respaldan el relato de ingeniería. El registro público conecta de forma menos convincente esos mecanismos con resultados económicos medidos en implantaciones. (5, 7, 8, 19)
Seriedad del proveedor
| Criterio | Puntuación |
|---|---|
| Seriedad técnica de la comunicación pública | 5/10 |
| Integridad de la hoja de ruta tecnológica | 7/10 |
| Claridad conceptual | 6/10 |
| Responsabilidad económica | 3/10 |
| Capacidad de defensa en un mundo de software agéntico | 7/10 |
Media: 5,6/10.
Seriedad técnica de la comunicación pública. La investigación explicita los compromisos experimentales. La garantía de seguridad y la calculadora económica optimista hacen afirmaciones que sus mediciones no sustentan. (5, 15, 20)
Integridad de la hoja de ruta tecnológica. La secuencia desde investigación en visión industrial hasta kits instalados es coherente. La aportación FPGA cuenta con experimentos concretos, aunque su continuidad dentro del hardware Spark actual no está resuelta. (3, 12, 14)
Claridad conceptual. Aprender el aspecto aceptable y reducir la carga de enumerar defectos aborda un problema industrial claro. Elegir el equilibrio de errores económicamente adecuado e incorporar incertidumbre de calidad en decisiones más amplias queda fuera de la metodología demostrada. (2, 5)
Responsabilidad económica. Una calculadora que suprime resultados negativos y presupone recuperar todos los costes no puede poner a prueba la propuesta comercial. Las declaraciones públicas de clientes y el material legal no aportan los criterios de aceptación ni los compromisos de corrección que faltan. (18, 19, 20)
Capacidad de defensa en un mundo de software agéntico. La óptica, la integración física, los datos del dominio y la validación sobre el terreno siguen siendo exigentes aunque los agentes reduzcan el coste de programación. La ventaja de Scortex depende de conservar esas capacidades prácticas y mejorar el mantenimiento de modelos, no de limitarse a ofrecer una interfaz de chat. (5, 16, 21)
Fuentes
Fuente pública. Consultada el 4 de noviembre de 2026.
Fuente pública. Consultada el 4 de noviembre de 2026.
Fuente pública. Publicación o fecha: 2026-08. Consultada el 4 de noviembre de 2026.
[4] Automatización del control de calidad en Toly gracias a Spark
Fuente pública. Publicación o fecha: 2024-06-26. Consultada el 4 de noviembre de 2026.
[5] Optimización de PatchCore para detectar anomalías con pocos/muchos ejemplos
Fuente pública. Publicación o fecha: 2023-07-20. Consultada el 4 de noviembre de 2026.
[6] Implementación de PatchCore con pocos ejemplos
Fuente pública. Publicación o fecha: 2023. Consultada el 4 de noviembre de 2026.
[7] Datos técnicos de Spark EN-23-11-V1
Fuente pública. Publicación o fecha: 2024. Consultada el 4 de noviembre de 2026.
[8] Datos técnicos de Spark EN-25-03-V4
Fuente pública. Publicación o fecha: 2025-03. Consultada el 4 de noviembre de 2026.
[9] Cartera de Notion: Scortex
Fuente pública. Consultada el 4 de noviembre de 2026.
[10] Cartera de Alven: Scortex
Fuente pública. Consultada el 4 de noviembre de 2026.
[11] Scortex, socio tecnológico de COGNITWIN
Fuente pública. Publicación o fecha: muestra 2019-12-04; editada posteriormente. Consultada el 4 de noviembre de 2026.
[12] Segundo boletín de COGNITWIN: plataforma FPGA de Scortex
Fuente pública. Publicación o fecha: 2021. Consultada el 4 de noviembre de 2026.
[13] Informe periódico final de COGNITWIN
Fuente pública. Publicación o fecha: 2023. Consultada el 4 de noviembre de 2026.
[14] TRIGO Group ha adquirido la startup industrial SCORTEX
Fuente pública. Publicación o fecha: 2022-05-06. Consultada el 4 de noviembre de 2026.
[15] Nuestro compromiso con la seguridad
Fuente pública. Publicación o fecha: muestra 2019-07-28; menciona el producto Spark posterior. Consultada el 4 de noviembre de 2026.
[16] Machine Learning & Computer Vision Platform Engineer
Fuente pública. Publicación o fecha: contratación de 2026; incorporación el 1 de junio. Consultada el 4 de noviembre de 2026.
[17] Compilar LinuxPTP para SparkOS y Wago RIOM-CC100
Fuente pública. Publicación o fecha: 2023. Consultada el 4 de noviembre de 2026.
[18] Condiciones de uso de la solución Scortex
Fuente pública. Consultada el 4 de noviembre de 2026.
Fuente pública. Consultada el 4 de noviembre de 2026.
[20] Calculadora de ROI: código público de cálculo
Fuente pública. Consultada el 4 de noviembre de 2026.
[21] Optical and Vision Technician: descripción del puesto por el empleador
Fuente pública. Consultada el 4 de noviembre de 2026.