Embed Size (px)
Citation preview
Proyecto de Grado
Sistema de Seguimiento para cadenas de suministro basado en Blockchain
Mateo Devia Vega 201630956 11-6-2020
Tabla de contenido 0. Resumen .................................................................................................................................... 3
1. Introducción .............................................................................................................................. 4
1.1 Agradecimientos ................................................................................................................. 4
1.2 Motivación .......................................................................................................................... 4
1.3 Enunciado del problema ..................................................................................................... 4
1.4 Discusión de lo que debería ser una solución ..................................................................... 4
1.4.1 Requerimientos Funcionales: ....................................................................................... 5
1.4.2 Requerimientos no Funcionales: .................................................................................. 5
2. Descripción General .................................................................................................................. 7
2.1 Objetivos ............................................................................................................................. 7
2.2 Marco Teórico ..................................................................................................................... 7
2.2.1 Introducción a Blockchain ............................................................................................ 7
2.2.2 Tipos de Blockchain ...................................................................................................... 7
2.2.3 Smart Contracts ............................................................................................................ 8
2.3 Identificación del problema ................................................................................................ 8
2.4 Justificación del uso de blockchain ..................................................................................... 8
2.5 Estado del Arte .................................................................................................................... 9
2.6 Plan de Trabajo .................................................................................................................. 10
3. Diseño y especificaciones ........................................................................................................ 11
3.1 Especificaciones de la solución ......................................................................................... 11
3.1.1 Requerimientos Funcionales ...................................................................................... 11
3.1.2. Requerimientos no Funcionales ................................................................................ 11
3.2 Restricciones ..................................................................................................................... 11
4. Desarrollo del diseño............................................................................................................... 13
4.1 Recolección de información .............................................................................................. 13
4.1.1 Etherium ..................................................................................................................... 13
4.1.2 Hyperledger ................................................................................................................ 13
4.2 Alternativas de diseño ....................................................................................................... 13
4.2.1 Etherium o Hyperledger ............................................................................................. 13
4.3 Arquitectura de Referencia ............................................................................................... 14
4.4 Arquitectura de Solución ................................................................................................... 15
4.4.1 Punto de vista de contexto ........................................................................................ 15
4.4.2 Punto de Vista de Información ................................................................................... 17
4.4.3 Punto de Vista Funcional ............................................................................................ 22
4.4.4 Punto de vista de despliegue ..................................................................................... 23
4.4.5 Punto de Vista de desarrollo .......................................................................................... 24
5. Validación del Diseño ............................................................................................................. 26
5.1 Caso de estudio ................................................................................................................. 26
5.2 Escenarios de Despliegue .................................................................................................. 28
5.2.1 Escenario 1 ................................................................................................................. 28
5.2.2 Escenario 2 ................................................................................................................. 29
5.2.3 Escenario 3 ................................................................................................................. 30
6. Implementación ...................................................................................................................... 31
6.1 Descripción de la implementación .................................................................................... 31
6.1.1 API .............................................................................................................................. 31
6.1.2 Visualización ............................................................................................................... 35
6.1.3 Aplicaciones Cliente ................................................................................................... 41
6.2 Resultado de la implementación ....................................................................................... 44
6.2.1 Despliegue .................................................................................................................. 44
6.2.2 Pruebas de Carga ........................................................................................................ 44
7. Conclusiones............................................................................................................................ 51
7.1 Discusión de los resultados ............................................................................................... 51
7.2 Trabajo Futuro ................................................................................................................... 52
8. Referencias .............................................................................................................................. 53
0. Resumen
Las cadenas de suministro son sistemas complejos y difíciles de controlar. Existen muchos tipos
de cadenas de suministro pertenecientes a diferentes industrias, y cada una tiene sus propios
procesos, actores, productos y medios de comunicación. El poder conocer los movimientos de los
diferentes activos a lo largo de estas complejas cadenas es de gran interés para muchos de los
involucrados, pero es un objetivo que muy pocos logran cumplir debido a que no es viable tener
toda la información de una cadena en un solo lugar centralizado.
Blockchain es una tecnología emergente que tiene el potencial de solucionar este problema gracias
a su arquitectura descentralizada y a la confianza que genera entre los diferentes actores de la red.
Sin embargo, el costo de implementación de un sistema Blockchain aún es muy alto por la
complejidad que esto implica, por lo que poner en producción una solución de este tipo es poco
viable para la mayoría de las cadenas de suministro. Este proyecto propone un diseño una
arquitectura de solución genérica para un sistema basado en Blockchain que es fácilmente
adaptable a cualquier cadena de suministro.
1. Introducción
1.1 Agradecimientos En esta sección se quiere agradecer a varias personas que estuvieron involucradas en el desarrollo
de este proyecto de grado. En primer lugar, a Darío Correal, subdirector academico del
departamento de ingeniería de sistemas y computación, quien fue mi asesor de proyecto de grado
por, siempre estar disponible para escuchar ideas y guiarme en las decisiones más importantes del
proceso. En segundo lugar, a Luis Esteban Flores, asistente doctoral y líder del Laboratorio
Blockchain de la Universidad de los Andes, por toda su ayuda y asesoría técnica en la
implementación del prototipo y en la concepción del proyecto. También a Santiago Vargas Vega,
director financiero de Cartoflex SAS, por su constante colaboración en el proceso de validación
del proyecto. Y, por último, a Carlos Vargas Osorno, gerente general de Cartoflex SAS, por
permitirnos usar a Cartoflex SAS como caso de estudio para la validación del proyecto.
1.2 Motivación Blockchain es una tecnología reciente que se popularizó gracias al éxito del Bitcoin. Bitcoin es
una criptomoneda que fue implementada en una red Blockchain publica que hoy en día tiene más
200 millones de usuarios [1]. Desde entonces, muchos han intentado utilizar esta tecnología en
dominios diferentes al de las criptomonedas, pero se han visto pocos casos de éxito, y ninguno de
la magnitud del Bitcoin. Desde la academia también se ha reconocido el potencial de esta
tecnología y uno de los dominios más prometedores para Blockchain son las cadenas de
suministro.
Una de las barreras más importantes a superar al implementar una solución Blockchain es la
complejidad técnica que requieren los sistemas basados en Blockchain. Al brindar una solución
lista para producción que se pueda usar en cualquier cadena de suministro, se sobrepasa esta
barrera inicial y se puede aprovechar al máximo los beneficios que Blockchain puede brindarle a
esta industria.
1.3 Enunciado del problema En general, las cadenas de suministro en cualquier tipo de industria se componen por la
interacción y comunicación entre varios actores u organizaciones que aportan a la transformación,
distribución, o producción de algún activo. Hacer un seguimiento global a una cadena de
suministro se considera un gran reto a nivel mundial dada su alta complejidad y la cantidad de
actores involucrados en el proceso. Esto se debe, en gran medida, a que una cadena de suministro
es un conjunto de procesos no centralizados pertenecientes a las diferentes empresas, por lo cual
es difícil recolectar toda la información necesaria para tener una visión clara del estado actual de
los activos.
1.4 Discusión de lo que debería ser una solución Para solucionar la problemática expuesta, se propone un diseño de arquitectura para un sistema
logístico de seguimiento a activos en una cadena de suministro basado en la tecnología
Blockchain, que sirva para cualquier tipo de cadena de suministro. A muy grandes rasgos
Blockchain es un libro de transacciones distribuido que puede ser compartido y verificado entre
varios actores de una red. La solución propone que todos los distintos actores de una cadena de
suministro tengan un libro de transacciones compartido en el cual registren todas las acciones
relevantes para la cadena de suministro de manera que cualquiera pueda revisar el estado actual
de cualquiera de los activos en la cadena. En esta sección se discuten algunas de las características
que debe tener la solución propuesta para que realmente sea una solución viable.
1.4.1 Requerimientos Funcionales:
Rastrear y hacer seguimiento a activos:
Una de las tareas más difíciles hoy en día en una cadena de suministro, es determinar dónde
termina un activo o sus derivaciones después de pasar por una cadena de suministro. Esta tarea se
vuelve particularmente complicada si el activo pasa por transformaciones que lo convierten en
varios activos diferentes que pueden terminar en diferentes destinos. El sistema logístico debe
poder brindarles esta información a todos los usuarios de una manera clara y concisa. Un posible
caso de uso en el que este requerimiento tomaría una gran importancia es en la industria de comida
cuando se detecta algún alimento que tiene algún tipo de contaminación. En este caso, es de gran
interés saber dónde terminó dicho activo para poder detectar todos los productos derivados del
alimento contaminado y poder tomar acciones al respecto.
Consultar procedencia de activos:
Otra tarea importante que se debe poder realizar en una herramienta como la que se plantea, es la
posibilidad de ver la procedencia de un activo en específico. Un caso de uso común para esta
funcionalidad es cuando se quiere verificar la autenticidad de un activo. Al ver exactamente de
dónde salió un producto y por qué intermediarios pasó, se puede verificar fácilmente si un activo
es auténtico y si cumple con todas las políticas y certificaciones adecuadas.
Registrar operaciones de los actores:
Una cadena de suministro puede verse como un conjunto de procesos que realizan diferentes
actores. Si se quiere conocer toda la actividad que se realiza en una cadena de suministro, el
sistema le debe permitir a los diferentes actores registrar las actividades que hagan como parte de
su operación y que sean relevantes para la cadena de suministro. Solo así se podrá tener en el
Blockchain toda la información necesaria para cumplir con los 2 requerimientos anteriormente
descritos.
Registrar transacciones entre actores:
Para poder tener un registro completo es necesario poder saber qué actor tenía la custodia de un
activo en cada momento con el fin de que los actores tengan que responsabilizarse en todo
momento de los activos que tienen bajo su custodia. Para lograr esto el sistema debe permitir a
los actores realizar transferencias de activos entre ellos para asi registrar en el sistema que uno o
más activos tuvieron un cambio de dueño.
1.4.2 Requerimientos no Funcionales:
Transparencia:
Todas las acciones o transacciones que se realicen en el sistema deben ser transparentes y visibles
por todos los involucrados para garantizar la legitimidad de la información.
Confianza:
Uno de los principales problemas a la hora de implementar sistemas en cadenas de suministro es
la falta de confianza que existe entre los actores. Para que un sistema logístico tenga éxito es
necesario que todos confíen en la informacion y para que esto se logre se deben dar garantías de
que la información es verídica y que no puede ser alterada por nadie, ni siquiera por los
administradores del sistema.
Incremento en la eficiencia:
El propósito general de cualquier sistema logístico es optimizar y mejorar la eficiencia de los
procesos logísticos involucrados. Por esta razon el sistema implementado no solo debe
acomodarse a los procesos actuales de las cadenas de suministro, sino que debe facilitar algunos
de los procesos generando un incentivo para que todo el mundo lo use.
Adaptabilidad:
Lo más importante de una solución de este tipo es que funcione para cualquier tipo de industria y
para cualquier tipo de actor. Esto no solo quiere decir que se adapte a las diferentes reglas de
negocio del dominio en cuestión, sino también que técnicamente debe ser fácil de implementar y
de integrar con los sistemas de información ya existentes en la cadena de valor.
Privacidad
Una realidad de la que se debe ser consiente es que para las empresas no será fácil compartir su
informacion de operación con los demas actores de la cadena de valor, sin embargo, para que la
herramienta funcione todos los actores deben compartir una cantidad mínima de información. Por
esta razón, el sistema debe poder adaptarse a diferentes niveles de detalle en la información para
que los actores que deseen compartir la mínima información posible puedan pertenecer a la red,
sin limitar a aquellos actores que están dispuestos a compartir todo el detalle de su operación en
la red.
2. Descripción General
2.1 Objetivos El principal objetivo del proyecto fue plantear un diseño de arquitectura genérico para
sistemas logísticos de seguimiento de cadenas de suministro basados en Blockchain
Implementar un prototipo funcional que cumpla con los principales requerimientos
funcionales necesarios para la solución.
Validar el diseño planteado y el prototipo con un caso de estudio real.
2.2 Marco Teórico Como marco teórico se desarrolló una revisión de los conceptos básicos de la tecnología
Blockchain que serán usados a lo largo de todo el documento para explicar la solución propuesta.
2.2.1 Introducción a Blockchain
Blockchain:
Es un libro contable distribuido que se guarda en una estructura de datos que representa una lista
de bloques. Cada bloque contiene un conjunto ordenado de transacciones. Esta lista está
encadenada por un hash que une cada bloque con su sucesor [9].
Sistema Blockchain (BCS):
Son sistemas que siguen el estilo de arquitectura P2P para compartir información almacenada en
un Blockchain. Estas redes mantienen replicada la información del Blockchain en cada uno de los
nodos pertenecientes a la red. Para que la información replicada sea igual en todos los nodos de
la red existen diferentes mecanismos de consenso como Proof of Work, Proof of Stake, o
Delegated Proof of Stake [9].
2.2.2 Tipos de Blockchain
Blockchain Público:
Es un BCS que está disponible para cualquier persona en el mundo pueda ser un nodo de la red.
En estas redes nadie está a cargo del BCS y cualquier nodo puede leer, escribir, y dar auditoría.
Las decisiones son tomadas por algoritmos complejos de consenso y por ende pertenecer a la
red es computacionalmente costoso. Por esta razón, las redes públicas cuentan con un
mecanismo de incentivo para que las personas hagan parte de la red. Este incentivo
generalmente es monetario [9].
Blockchain Privado:
Es un BCS operado por una organización. En estas redes hay un nodo administrador que vela
por los permisos y las identidades de los nodos que participan en la red. En estas redes los
mecanismos de consenso son definidos por el administrador y puede o no requerir validación de
los otros nodos de la red [9].
Blockchain Consorcio:
Es un BCS operado por un conjunto de organizaciones en donde la administración está
distribuida entre las organizaciones. Estas redes son particularmente útiles porque distribuye el
control de la red entre varios nodos lo que evita que haya un único punto de falla [9].
2.2.3 Smart Contracts
Smart Contract:
Es un fragmento de código que es introducido al Blockchain para que este sea conocido por toda
la red, y además pueda ser ejecutado por todos los nodos de forma que estos puedan certificar el
resultado de la ejecución. Estos contratos permiten realizar transacciones y verificar reglas de
negocio, para que todas las acciones que se tomen en el sistema estén acordes a las normas del
negocio [9].
Decentralized App (Daap):
Es un conjunto de smart contracts distribuidos a lo largo de una red Blockchain que pueden
entenderse como una aplicación que se ejecuta en muchas maquinas [9].
2.3 Identificación del problema Hacer un seguimiento global a una cadena de suministro se considera un gran reto a nivel mundial
dada su alta complejidad, la cantidad de actores involucrados en el proceso y la descentralización
de la informacion. Blockchain es una tecnología que promete ser una solución para este problema
gracias a su arquitectura descentralizada que permite a diferentes actores compartir su
información a través de una red. Sin embargo, la complejidad y el costo de desarrollar una
solución Blockchain aún es muy alto para que sea viable ponerlo en producción en una cadena de
suministro.
2.4 Justificación del uso de Blockchain Gracias a sus innovadoras características, Blockchain es una tecnología que ha causado un gran
interés en la academia, pero existen pocos ejemplos de proyectos Blockchain exitosos en la
industria ya que justificar el uso de esta tecnología es difícil en la mayoría de los casos. A
continuación, se exponen los beneficios que trae Blockchain a las cadenas de suministro y por
qué sin ellos un sistema logístico como el planteado en la sección 1.4 no sería exitoso.
Inmutabilidad:
La información del Blockchain se guarda en una estructura de datos que usa técnicas
criptográficas para asegurar que una vez se agregue una cierta transacción sea prácticamente
imposible cambiar esa información. Esto, junto con el hecho de que la información esté replicada
en una red de nodos, aseguran que la información allí persistida es inmutable, es decir, nunca va
a cambiar. En nuestro contexto, esta propiedad del Blockchain garantiza que toda acción que se
haga siempre va a estar disponible para que los entes interesados la vean, y además garantiza el
no repudio. Esto mitiga el riesgo de que algún actor quiera tomar acciones ilícitas como robarse
activos, o venderlos a actores no autorizados.
Ejecución distribuida:
Blockchain tiene una arquitectura distribuida donde los componentes de software se ejecutan en
diferentes maquinas pertenecientes a los diferentes actores de la red y los resultados de cualquier
transacción son verificados y aprobados por todos los nodos. Esto permite que ningún actor tenga
más control que otro sobre el sistema, y asi las diferentes empresas de la cadena de suministro se
encontraran en igualdad de condiciones dentro del sistema.
Información Distribuida
Toda la información que se introduzca en el Blockchain se replica en todos los nodos de la red, o
por algunos nodos dependiendo de la implementación que se escoja. Esto permite que aquellos
que estén autorizados, podrán ver todas las acciones que han registrado los distintos actores de la
red. De esta manera, se logra que cualquier actor pueda consultar el estado de todos los activos
de interés en la cadena de suministro.
Transacciones entre actores sin intermediario:
Blockchain permite que 2 actores puedan intercambiar información, o realizar transacciones entre
ellos sin necesidad de que exista un intermediario que centralice la información en un solo lugar.
Normalmente este tipo de intermediarios son los encargados de decidir qué transacciones son
válidas ya que la información que ellos poseen es considerada como la verdad absoluta. Lo
anterior es una desventaja ya que el intermediario potencialmente podría cambiarla ilícitamente
o ser víctima de un ataque que modifique la información. Como en las cadenas de suministro no
hay una sola entidad central que coordine el proceso, sino que existen varias entidades autónomas
que participan en diferentes partes de los procesos, el paradigma computacional de Blockchain se
acopla perfectamente a la naturaleza del negocio.
Validación de reglas de negocio:
Otro concepto muy importante de la tecnología Blockchain son los smart contracts. Estos
contratos permiten realizar transacciones y verificar reglas de negocio, para que todas las acciones
que se tomen en el sistema estén acordes a las normas del negocio.
2.5 Estado del Arte Se realizó una investigación inicial sobre el estado del arte de esta problemática y como se ha
usado la tecnología Blockchain en este contexto. Existen varios estudios que han explorado la
tecnología Blockchain como una solución para la logística de las cadenas de suministro. Por
ejemplo, Shuian Wang y Xiabo Qu [2] realizaron un estado del arte en el cual especifican los
beneficios que traería Blockchain al dominio de las cadenas de suministro. Estas siendo: pagos
rápidos, información compartida, monitoreo y seguimiento, y verificación de la propiedad. Mann
Suruchi et al. [4] también realizaron un estudio sobre los beneficios de Blockchain en esta
industria, y resaltaron como caso de estudio real la automatización que llevo a cabo la empresa
Oracle con IBM al integrar Blockchain a su ERP.
Por otro lado, otros investigadores como Peti Helo et al. [3], Henry M. et al. [5], Saungen Kim et
al. [6], y Tsenthil et al. [7], Riveros D. et al. [8] han ido más allá y han desarrollado prototipos
como una prueba de concepto para los sistemas de cadena de suministro basados en Blockchain.
En general los prototipos propuestos por estos autores tienen varias características en común.
Hacen uso de smart contracts para implementar las reglas de negocio. La gran mayoría usan
Etherium como infraestructura para desplegar dichos contratos, a excepción de Saungen Kim et
al. [6] y Riveros D. et al. [8] quienes usan Hyperledger. Por otro lado, todos desarrollaron una
arquitectura en la cual una interfaz web que se comunica con un servidor web que funciona como
un intermediador entre el cliente y la red Blockchain.
Entre estos autores se destacan Henry M. et al. [5] por su aproximación de diseño basada en
ontologías. Ellos se basaron en una ontología diseñada para cadenas de suministro llamada TOVE.
Esta ontología fue su marco de referencia para el diseño de un metamodelo UML el cual fue usado
para modelar de manera abstracta los principales conceptos de una cadena de suministro
cualquiera. El uso de UML fue justificado dado el paradigma del lenguaje en el cual se
implementaron los contratos ya que era orientado a objetos. El resultado final, fue nuevamente
una interfaz web que es capaz de rastrear la procedencia de un activo a lo largo de una cadena.
Este estudio es muy importante porque la arquitectura propuesta en este proyecto toma algunos
de los conceptos de este meta modelo como inspiración para el modelaje de la cadena de valor.
2.6 Plan de Trabajo El desarrollo del proyecto se realizó en 5 etapas principales que se describen a continuación. El
proyecto tuvo una duración de 16 semanas donde se tuvieron reuniones semanales de
aproximadamente 1 a 2 horas donde se mostraban los avances y se establecían tareas concretas
para desarrollar en la semana posterior.
1. Entendimiento del problema
Apropiación de conceptos fundamentales de la tecnología Blockchain
Investigación del estado del arte
Concepción del proyecto y sus objetivos
2. Diseño de la solución
Diseño de la arquitectura de referencia
Diseño de la arquitectura de solución
Diseño del API
Diseño de la visualización
3. Implementación del prototipo
Implementación del API
Implementación de la visualización
4. Validación
Definición del caso de estudio
Documentación del caso de estudio
Generación de datos para el caso de estudio
Implementación de aplicaciones para el caso de estudio
Despliegue
Pruebas de carga
5. Documentación
Desarrollo del documento de proyecto de grado
Desarrollo del poster de proyecto de grado
3. Diseño y especificaciones
3.1 Especificaciones de la solución En esta sección se documenta más formalmente los requerimientos del prototipo que se
implementó para el proyecto. Para este propósito, se utilizó historias de usuarios como mecanismo
de especificación de requerimientos tanto funcionales como no funcionales.
3.1.1 Requerimientos Funcionales ID Nombre Historia de usuario
RF1 Consultar
Procedencia de un
activo
Como actor de la cadena de suministro, quiero conocer todos los
activos y procesos que fueron necesarios para producir un activo
especifico al igual que los actores que estuvieron involucrados,
para poder tener claridad sobre la procedencia del activo en
cuestión.
RF2 Rastrear un activo Como actor de la cadena de suministro, quiero conocer los
procesos y actividades en los que estuvo involucrado un activo y
todos los activos derivados de él, para poder hacerle un
seguimiento detallado y conocer su estado actual.
RF3 Registrar Actividad Como actor de la cadena de suministro, quiero poder registrar
todas las actividades que realizo sobre un conjunto de activos, para
poder justificar el estado final de los mismos ante los demas
actores en la red.
RF4 Registrar
Transaccion
Como actor de la cadena de suministro, quiero poder registrar la
transferencia de un conjunto de activos a otro actor de la cadena,
para que el resto de actores de la red se enteren que dichos activos
ya no se encuentran bajo mi custodia. Tabla 1. Requerimientos Funcionales
3.1.2. Requerimientos no Funcionales ID Nombre Historia de usuario
RNF1 Transacciones
publicas
Como actor de la cadena de suministro, quiero que todas las
actividades que se registren en el sistema sean visibles ante todos
los actores de la red, para que no haya posibilidad de que algún
actor o grupo de actores realicen actividades de forma oculta.
RNF2 Integridad de la
información
Como actor de la cadena de suministro, quiero que la información
persistida en el sistema no pueda ser modificada en ningún
momento, para garantizar la veracidad de la misma.
RNF3 Verificación de
reglas de negocio
Como actor del sistema, quiero poder especificar reglas de
negocio y que el sistema valide el cumplimiento de estas antes de
persistir la información, para así volver más eficiente mi
operación y para poder estar seguro de que la información
persistida sea coherente. Tabla 2. Requerimientos No Funcionales
3.2 Restricciones Para el desarrollo de este proyecto teníamos restricciones tanto económica como restricciones de
tiempo. La restricción más importante fue que el proyecto tenía que desarrollarse en un periodo
de 4 meses con fecha máxima de culminación el 11 de junio de 2020. En cuanto a las restricciones
económicas, no contábamos con ningún presupuesto para el desarrollo del proyecto, por lo que
solo podíamos contar con los recursos que provee la Universidad de los Andes para sus
estudiantes de pregrado. Adicionalmente, durante el transcurso del proyecto se consiguió una
membresía educativa en Microsoft Azure, que nos permitió utilizar la infraestructura de este
proveedor para el despliegue del prototipo. Sin embargo, la membrecía educativa nos limitaba el
consumo a $5000 dólares anuales, pero la membresía debía ser compartida con otros 2 proyectos
que del Laboratorio Blockchain de la universidad y tambien se esperaba que el crédito alcanzara
para los proyectos del próximo semestre.
4. Desarrollo del diseño
4.1 Recolección de información En esta sección se exploran 2 alternativas para la implementación del diseño propuesto.
Concretamente se exploran 2 proyectos open source que fueron creados para el desarrollo de
sistemas basados en la tecnología Blockchain.
4.1.1 Ethereum Ethereum es una plataforma open source que usa la tecnología Blockchain para crear un
ecosistema en el que se pueden desarrollar aplicaciones distribuidas (Daaps). Está basado en el
concepto de máquinas virtuales ya que esencialmente es una máquina virtual distribuida que es
capaz de ejecutar scripts en diferentes nodos y consolidar un resultado de las diferentes
ejecuciones. La red de Ethereum es una red pública que es sostenida usando como incentivo una
la criptomoneda conocida como Ether. En el momento en el que se escribe este documento, un
Ether está avaluado en $757,174.23 COP. Las aplicaciones en Ethereum deben ser escritas
utilizando un lenguaje desarrollado específicamente para Ethereum llamado Solidity [9]. Para
consultar información más detallada sobre Ethereum se tomó como referencia el sitio oficial del
proyecto [11].
4.1.2 Hyperledger Hyperledger es un proyecto open source creado por Linux Fundación para el desarrollo de
soluciones privadas de Blockchain a nivel empresarial. Es una suite de frameworks y herramientas
que permiten implementar diferentes tipos de sistemas Blockchain con características propias
para el dominio. Este proyecto es mantenido por varios de los jugadores clave de la economía
global. [9] Para consultar información más detallada sobre Hyperleger se tomó como referencia
el sitio oficial del proyecto [10].
4.2 Alternativas de diseño
4.2.1 Etherium o Hyperledger Después de la investigación, Hyperledger fue la herramienta escogida para la implementación del
prototipo ya que según los objetivos del proyecto se requiere de un BCS de tipo consorcio al cual
solo pueden acceder los actores pertenecientes a la cadena de suministro. Además, teniendo en
cuenta la restricción de tiempo que se tenía para el proyecto y que el objetivo principal del
proyecto era una propuesta de diseño más que la implementación de un producto listo para
producción, se determinó que Hyperledger sería la herramienta que nos permitiría implementar
un prototipo con mayor facilidad gracias a que los asesores del proyecto ya tenían una experiencia
previa con Hyperledger. Adicionalmente, Hyperledger tiene compatibilidad con lenguajes como
Java, Go y JavaScript, lo cual se alinea con el objetivo de que la solución sea fácilmente adaptable
a sistemas ya existentes en las cadenas de suministro.
Específicamente, dentro de los distintos frameworks ofrecidos por Hyperledger se utilizó
Hyperledger Fabric que ofrece una solución modular para implementar redes Blockchain privados
a escala empresarial. Hyperledger Fabric brinda una gran flexibilidad de implementación ya que
permite manejar transacciones privadas entre peer, o manejar canales en la red para que no todo
el mundo se entere de cada transaccion [9]. Para la implementación del sistema, la principal
referencia fue la documentación oficial de Hyperledger Fabric [12].
4.2.1.1 Lenguajes
Hyperledger Fabric es un framework, asi que provee varias alternativas para la implementación
de soluciones Blockchain. Una de las decisiones a tomar son los lenguajes a usar tanto para las
aplicaciones, como para los smart contracts.
Para la implementación de los smart contracts las alternativas ofrecidas actualmente son Go
JavaScript y Java. Para el desarrollo de las aplicaciones, Fabric ofrece SDKs para Java y
JavaScript. Se escogió utilizar JavaScript tanto para las aplicaciones como para los contratos con
el propósito de mantener un stack tecnológico estandarizado. Adicionalmente, al ser JavaScript
el lenguaje más usado a nivel mundial, usar JavaScript se alinea nuevamente con el objetivo de
desarrollar una solución fácilmente adaptable a cualquier industria.
4.2.1.2 Base de datos
Otra decisión a tomar al usar Hyperledger Fabric es la base de datos a usar. Fabric maneja un
concepto llamado state database. Esta es una base de datos tradicional en la cual se guarda el
estado actual de los objetos del sistema. Claro está que todo el historial de la informacion siempre
queda persistido en el Blockchain de manera inmutable, pero en la state database se guarda la
información más reciente. Hyperledger actualmente provee 2 alternativas para esta base de datos
que son LevelDB y CouchDB.
Ambas bases de datos guardan la información en formato Key-Value. Sin embargo, la principal
diferencia es que los valores de CouchDB se guardan en formato JSON. LevelDB tiene su propio
sistema de sentencias para consultar la información de base de datos. Por otro lado, CouchDB
utiliza Mango que es un lenguaje de sentencias estándar basado en JavaScript. Dado que el stack
tecnológico escogido está completamente basado en JavaScript, se escogió CouchDB. Además,
el uso de JSON para guardar la información nos da mayor flexibilidad a la hora de modelar el
dominio lo cual es un aspecto crítico en el proyecto.
4.3 Arquitectura de Referencia Como parte del proyecto se documentó una arquitectura de referencia como un preámbulo
para la arquitectura de solución que se plantea para el proyecto. Esta arquitectura fue basada en
la arquitectura de referencia propuesta por el proyecto de grado de Riveros et al [8]. La
arquitectura fue planteada en capas que abstraen en diferentes niveles los conceptos relevantes
para un sistema Blockchain. El siguiente diagrama de muestra la arquitectura de referencia
planteada.
Figura 1. Arquitectura de Referencia
4.4 Arquitectura de Solución Para la arquitectura de solución se planteó un diseño pensado para favorecer ante todo la
mantenibilidad y la adaptabilidad. El principal objetivo del proyecto es que la arquitectura sea
genérica y suficientemente flexible para que logre cubrir las necesidades de cualquier cadena de
suministro. Con esto en mente las siguientes secciones documentan la arquitectura diseñada desde
diferentes puntos de vista
4.4.1 Punto de vista de contexto Para modelar adecuadamente el contexto, se definieron 6 tipos de actores con los que se puede
representar todos los actores que pueden hacer parte de una cadena de suministro y que podrían
llegar a interactuar con el sistema. A continuación, se definen los 6 tipos:
Productor:
Un productor es un actor que genera el activo más primitivo en la cadena de suministro. Algunos
ejemplos de actores que entrarían en esta clasificación serían productores de semillas, donantes,
o mineros de algún mineral o recurso natural.
Transformador:
Un transformador es un actor que recibe uno o más activos y los usa para transformarlos en uno
o más activos diferentes. Algunos ejemplos de actores que entrarían a esta clasificación serían las
fabricas industriales, carpinteros, o restaurantes.
Transportador:
Un transportador un actor que se dedica a movilizar uno o más activos de una ubicación geográfica
a otra. Los actores que entrarían en esta clasificación serían las empresas que se dedican a brindar
servicios de transporte, como por ejemplo Servientrega o Rappi.
Distribuidor:
Un distribuidor se define como un actor intermediario que recibe activos, los almacena, y/o los
transporta hasta entregárselo a otro actor de la cadena. Los distribuidores no transforman el estado
de un activo más allá de los cambios que puedan ocurrir por condiciones ambientales. Es decir,
los únicos cambios que pueden ocurrir en los activos mientras estén bajo la custodia de un
distribuidor son cambios naturales, como que un alimento cumpla su fecha de caducidad, o que
un activo cualquiera se dañe por vejez. Es importante resaltar que esta definición es diferente a lo
que se entiende comúnmente por distribuidor. En lenguaje natural se le llama distribuidor a aquel
que transporta y distribuye activos en diferentes ubicaciones geográficas. Sin embargo, con la
definición propuesta se pretende abarcar también a los actores que solamente reciben activos y
los guardan por un periodo de tiempo en una misma ubicación como por ejemplo en una bodega.
Algunos ejemplos de actores que entrarían en esta clasificación son la Panamericana, los
supermercados, las tiendas de barrio, o las droguerías.
Ente regulador:
Un Ente regulador es un actor que se encarga de intervenir en diferentes partes de la cadena para
revisar la calidad de los activos, y en caso de que no cumplan los estándares requeridos tiene la
potestad de invalidarlos. Este actor es muy particular porque no necesariamente representa un ser
humano. El ejemplo más básico serían entidades de control de salubridad como el INVIMA o la
DIAN las cuales hacen auditorias para garantizar la calidad o la legalidad de los productos. En
caso de que algún activo no cumpla con las condiciones estipuladas ellos pueden confiscar y/o
desechar dichos productos lo que para la cadena de suministro significaría que ese activo quedaría
invalido porque dejaría de circular con la cadena.
Por otro lado, en un entorno más automatizado, dispositivos de monitoreo como sensores o
cualquier tipo de dispositivo IoT que este encargado de monitorear alguna métrica específica para
validar la calidad del activo tambien podrían considerarse como un ente regulador. Esto ya que
podrían avisarle al sistema que un activo en particular ya no es válido porque no cumple con los
estándares mínimos. Un ejemplo de esto se podría dar en la industria de los bancos de sangre
donde los hemocomponentes deben ser almacenados a cierta temperatura. En este caso
probablemente debe existir un sistema que mediante sensores de temperatura monitorea que dicha
temperatura se mantenga, y en caso de que no sea así, se debe tener un sistema de alertas para que
se tome una acción al respecto. Con un sistema basado en Blockchain se podría automatizar el
proceso para que los mismos dispositivos que monitorean la temperatura sean los que registren la
situación en el Blockchain. De esta forma se garantiza que toda la red se entere que dicho activo
o activos no cumplen con los estándares de calidad exigidos, y, por ende, debería dejar de circular
en la cadena. Asi tambien se mitigaría el riesgo de que el actor responsable de mantener dicha
temperatura intente ocultar la situación.
Consumidor:
Un consumidor es el último actor de la cadena, el cual consume un activo y/o adquiere propiedad
sobre él. Este tipo de actor se puede entender básicamente como el usuario final que consume o
adquiere el producto producido por la cadena de suministro. En caso de que se quiera lograr un
seguimiento muy exhaustivo el usuario final podría clasificarse como un distribuidor que
almacena el activo por cierto tiempo y eventualmente cuando lo deseche el consumidor sería la
entidad de desechos que se encargue de procesar el producto desechado, como por ejemplo el
relleno sanitario Doña Juana. Sin embargo, obtener este tipo de información es poco viable.
El siguiente diagrama de contexto muestra el ambiente en el que se encontrará nuestros sistemas.
Se puede ver que todos los actores interactúan directamente con el sistema si ningún intermediario
y que el sistema comunica con el Blockchain para persistir la información.
Figura 2. Diagrama de Contexto
4.4.2 Punto de Vista de Información Para el punto de vista de información se empezó modelando el dominio de las cadenas de
suministro. Para esto se definieron 5 entidades principales con las que se encapsulan los
principales conceptos de una cadena de suministro. Para empezar, se definió la entidad
fundamental de la arquitectura basado en los estudios de H. M. Kim y M. Laskowski (2018) [5].
De este estudio se adoptó el termino Traceable Resource Unit (TRU) y se definió como un activo
de una cadena de suministro que se encuentra en un estado determinado. El estado de un TRU se
entiende como el conjunto de características que tiene el activo en un determinado momento. Esto
quiere decir que si una de las características del TRU cambia es considerado un nuevo TRU.
Claramente las características de un TRU cambian dependiendo del dominio en el que se esté
trabajando. Por esta razon, se definió la entidad Característica para lograr modelar las
características cambiantes que puede tener un TRU. A partir de esto se definieron las otras 3
entidades de la siguiente manera.
Actor:
Persona, organización o dispositivo que participa en la cadena de suministro y que tiene la
responsabilidad de registrar en el sistema el manejo que le da a los activos. Esta entidad encapsula
los 7 tipos de actores que se definieron en el punto de vista de contexto.
Transaccion:
Es la acción de transferir la custodia sobre un conjunto de TRUs de un actor a otro. Esto
representaría acciones como vender, prestar o entregar que son muy comunes en cadenas de
suministro.
Actividad:
Es una acción que realiza un actor sobre un conjunto de TRUs y que tiene como resultado un
conjunto de TRUs diferentes.
Con estas 5 definiciones se construyó un primer diagrama de dominio que se puede observar en
la figura 3. El proposito de este diagrama es mostrar las relaciones existentes entre las 5 entidades
definidas. Para esto se utilizo UML ya que el stack tecnologico escogido usa JavaScript como
principal lenguaje de programación, y como JavaScript es su mayor parte un lenguaje orientado
a objectos, se ajusta al estandar de UML.
Figura 3. Diagrama de dominio
En este diagrama podemos ver que un TRU está compuesto por un conjunto de características
como se había mencionado anteriormente. Por otro lago un actor tiene un conjunto de actividades
realizadas, y cada una de estas actividades consume y produce conjuntos de TRUs.
Adicionalmente, vemos que las transacciones siempre tienen un conjunto de TRUs asociado y
tiene 2 actores, aquel que posee los TRUs e inicia la transaccion, que se denomina fuente, y aquel
que recibe los TRUs, que se denomina destino.
Posteriormente se desarrolló una mayor especificación para las actividades ya que la definición
que principal es muy abstracta y un poco ambigua. Para esto se definieron 6 tipos de actividades
como se muestra a continuación.
Producir:
Es una actividad que realiza un actor en la cual se producen un conjunto de TRUs sin consumir
ningún TRU. Es decir, el conjunto de TRUs consumidos siempre es vacío.
Transformar:
Es una actividad que realiza un actor en la cual toma como entrada un conjunto de TRUs y produce
como salida un conjunto de TRUs con características diferentes.
Transportar:
Es una actividad que realiza un actor en la cual toma un conjunto de TRUs y produce un conjunto
del mismo tamaño con TRUs que se encuentran en ubicaciones geográficas diferentes y por lo
tanto son TRUs diferentes. En esta actividad los TRUs producidos representan los mismos activos
que se consumen, sin embargo, como se encuentran en una ubicación geográfica diferentes se
modelan como TRUs diferentes. Además, en el trayecto pudieron haber cambiado otras
características ya sea por condiciones naturales o por accidentes, lo que significa que la ubicación
puede no ser la única característica que cambie durante la actividad de transportar, pero si es una
característica que tiene que cambiar para que la actividad sea considerada de tipo Transformar.
Invalidar:
Es una actividad que realiza un actor en la cual se consume un conjunto de TRUs para registrar
que dicho conjunto ya no es válido porque no cumple con algún estándar establecido, y por ende,
debe dejar de circular por la cadena de suministro. El conjunto de TRUs producidos por esta
actividad siempre es vació.
Consumir:
Es una actividad que realiza un actor de tipo consumidor en la cual consume un conjunto de TRUs
y no produce ningún TRU ya que este actor fue el beneficiario final de la cadena de suministro.
Es evidente que existe una relación entre los 6 tipos de actores y los 5 tipos de actividades
definidas. Sin embargo, esta relación no es uno a uno ya que, aunque sí existen tipos de actividades
solo pueden ser realizadas por un tipo de actor, hay otras que pueden ser realizadas por más de un
tipo de actor. La siguiente tabla ilustra de manera precisa cuales son los tipos de actividades que
puede realizar cada uno de los actores definidos.
Producir Transformar Transportar Invalidar Consumir
Productor X X X
Transformador X X X
Transportador X X
Distribuidor X X
Ente Regulador X X
Consumidor X Tabla 3. Distribución de actividades
La tabla muestra que hay actividades que casi cualquier actor puede hacer, y esto se hizo para
permitir una mayor flexibilidad y adaptarse a cualquier caso. Por ejemplo, Transportar es una
actividad que normalmente la hace un transportador, sin embargo, existen casos en que la misma
empresa que produce los activos se encarga de transportarlos, al igual que hay casos en que los
transformadores tambien asumen la responsabilidad del transporte y por eso no se puede limitar
esa actividad a un solo actor. Estas nuevas especificaciones las podemos observar en el siguiente
diagrama de dominio.
Figura 4. Diagrama de Dominio Extendido
Como ya se explicó en la sección 4.2.1.2, al usar Hyperledger se requiere de una base de datos de
estado para mantener la version más reciente de la información. Para el proyecto se escogió usar
CouchDB la cual es una base de datos llave-valor, pero el valor se guarda en formato JSON, lo
que hace que se comporte como una base de datos documental. El siguiente diagrama muestra
cómo se van a representar las diferentes entidades definidas en el diagrama de dominio en los
documentos de la base de datos.
Figura 5. Diseño de la base de datos
La figura 5 muestra que se tienen 4 tipos de documentos, Actores, Transacciones, TRUs y
Actividades. Los actores y las transacciones son documentos sencillos que solo tienen los
atributos establecidos en el diagrama de dominio. Los TRUs tienen los atributos propios del TRU,
pero adicionalmente tienen un arreglo de las transacciones en las cuales estuvieron involucrados.
Esto se hace con el fin de optimizar consultas sobre los actores que han intervenido por un TRU.
Por último, tenemos los documentos que representan actividades. Estos son los documentos más
importantes porque en ellos se va a contener toda la informacion necesaria para reconstruir la
historia de una cadena de suministro. Los documentos de las actividades tienen por dentro copias
redundantes de los TRUs que consumen, y los TRUs que producen, y cada uno de esos TRUs
tienen nuevamente una copia de las transacciones en las que han estado involucrados. Estas
decisiones se tomaron para mejorar el desempeño de las consultas referentes a consultar la
procedencia de un activo y hacerle seguimiento a un activo que son necesarias para cumplir con
los requerimientos funcionales RF1 y RF2. Estas consultas tienen una complejidad alta porque se
requiere que a partir de un TRU se pueda reconstruir toda la serie de eventos que ocurrieron en la
cadena de valor antes o después de la aparición de ese TRU.
Para la consulta de conocer la procedencia de un TRU a la cual nos referimos como la consulta
de origen, se requiere conocer todas las actividades, transacciones y activos que fueron necesarias
para que ese TRU fuera creado. Por esto, el documento de cada TRU tiene una referencia a la
actividad por la cual fue producido. Con esa referencia se puede encontrar el documento de dicha
actividad, y como cada actividad incluye una copia de los TRUs que consumió, se puede consultar
en cada uno de esos TRUs las actividades que los produjeron y asi repetir el proceso hasta que se
llegue a actividades de tipo producir las cuales se consideran como el origen del activo. La
siguiente imagen ilustra cómo se reconstruye la historia de un TRU navegando las referencias a
las actividades.
Figura 6. Consulta de origen
En la imagen se puede ver que se forma una estructura de tipo árbol donde los nodos son las
actividades. Para la consulta requerida en el RF2 a la que nos referimos como la consulta de
destino, se realiza una estrategia muy similar. Cada TRU tiene una referencia a la actividad que
lo consumió a menos que no haya sido consumido. Entonces se realiza el mismo procedimiento
hasta que se llegue a actividades que sean de tipo consumir, o hasta que hayan TRUs que no hayan
sido consumido como se muestra a continuación.
Figura 7. Consulta de destino
4.4.3 Punto de Vista Funcional En cuanto al punto de vista funcional, se diseñaron diferentes componentes en el sistema para
garantizar el modularidad y la adaptabilidad del código. El siguiente diagrama de componentes
muestra los principales componentes del sistema y como estos se comunican entre sí.
Figura 8. Diagrama de Componentes
En este diagrama vemos que cada actor debe tener un front-end que permita a los usuarios
interactuar fácilmente con el sistema. El diseño e implementación de dicha interfaz gráfica sería
responsabilidad de cada uno de los actores para que se adapte a sus procesos y sus necesidades
particulares. Todas estas aplicaciones clientes se comunicarán con un API REST que encapsula
las funcionalidades de acceso al Blockchain y las expone como servicios. Dichos servicios están
definidos en términos de las entidades que definimos en nuestro diagrama de dominio. El
componente del back-end se comunica con el componente On-chain que es donde se encuentran
los smart contracts y el Blockchain como tal. Esta comunicación se hace usando el SDK de
Hyperledger y los smart contracts a su vez se comunican con el componente Off-chain que es
donde se encuentra la base de datos de estado que en este caso es CoachDB.
4.4.4 Punto de vista de despliegue Como este sistema está basado en Blockchain, cuenta con una arquitectura distribuida y por esta
razon la vista de despliegue es una de las más complejas e importantes del diseño propuesto. El
siguiente diagrama de despliegue muestra cómo sería el despliegue del sistema diseñado. Dada la
complejidad, el diagrama se sale un poco de la notación estándar de UML para resaltar y aclarar
elementos importantes.
Figura 9. Diagrama de Despliegue
En el diagrama se usó el color rojo para delimitar las maquinas que hacen parte de la red
Blockchain. Además, se pintaron de diferentes colores los nodos de ejecución que pertenecen a
un actor de la cadena de suministro en específico. Por ejemplo, los nodos naranjas corresponden
a un productor de la cadena, y los verdes a un transformador. Los actores que se escogieron para
el diagrama son ilustrativos ya que la configuración cambiaría dependiendo del número de actores
que haya en la cadena de suministro. Lo importante es que por cada actor se tendrá una aplicación
cliente que corre en los dispositivos de los usuarios, un servidor web que expone el API, un
servidor web que sirve como entidad certificadora, y una máquina virtual que será el Peer que
hace parte de la red Blockchain. Cabe resaltar que los 2 servidores web y el Peer pueden todos
hacer parte de la misma maquina física, pero si se requiere que cada actor cuente por lo menos
con un servidor como requisito mínimo de infraestructura para poder hacer parte de la red. Más
adelante se proponen otros escenarios, pero esta sería la configuración de despliegue ideal para
que todos los actores estén en igualdad de condiciones.
4.4.5 Punto de Vista de desarrollo La organización del proyecto fue basada en su mayor parte en los tutoriales ofrecidos en la página
oficial de Hypeledger Fabric [13]. El siguiente diagrama muestra la organización del proyecto.
Figura 10. Diagrama de Paquetes
El diagrama muestra que se tienen 3 principales paquetes en el proyecto. El primero es el paquete
apps en el cual se tienen las aplicaciones Node JS y Express JS que implementan el back-end
API. Estas aplicaciones corresponden a las aplicaciones que se ejecutaran en los servidores web
de cada actor. Cada una de estas aplicaciones tiene a su interior un front-end que son los clientes
web que consumen los servicios ofrecidos por el API. Estas aplicaciones son servidas
estáticamente por los servidores de Express JS. El segundo paquete network contiene toda la
configuración de la infraestructura de la red Blockchain. Tiene un conjunto de script que
automatizan el despliegue de la red.
Por último, se tiene el paquete de smart contracts, en el cual hay algunos scripts para el despliegue
de los contratos en la red y en el sub paquete contract está el código fuente de los smart contracts.
En el archivo index.js están los contratos que son invocados desde los servidores web. Estos
contratos codifican todas las reglas de negocio establecidas en nuestra arquitectura. En este
archivo se encuentran funciones como crearTransaccion, o crearActividad que corresponden a la
creación de entidades definidas en el punto de vista de información. En el archivo domainLogic.js
se encuentran todas las reglas de negocio especificas al dominio en cuestión. Este archivo tiene
reglas que permiten determinar cosas como cuando una transformación es válida en el dominio,
o cuando tiene sentido invalidar un TRU. Las funciones de este archivo son invocadas por las
funciones de index.js. De esta forma se garantiza la mantenibilidad y la adaptabilidad del código.
Cuando se quiera implementar un BCS para un dominio en particular siguiendo la arquitectura
propuesta, solo se debe modificar el archivo domainLogic.js y las aplicaciones clientes. Las
demas reglas pertenecientes al modelo abstracto de las cadenas de dominio están en index.js y
estas son iguales para cualquier tipo de cadena de suministro.
5. Validación del Diseño
Para validar el diseño de la arquitectura, y especialmente el modelaje abstracto de las cadenas de
suministro, se tomó como caso de estudio la empresa colombina Cartoflex SAS. Cartoflex es una
empresa manufacturera que se dedica a la producción de láminas de polipropileno para diferentes
usos industriales. Una de sus principales productos son las láminas alveolares las cuales tienen
diferentes usos. Con la colaboración de Santiago Vargas, el director financiero de Cartoflex se
documentó el proceso de producción de esta línea de producto y se implementó un prototipo de
la arquitectura propuesta el cual permite registrar dicho proceso en el Blockchain y cumple con
los requerimientos funcionales y no funcionales especificados en secciones anteriores.
5.1 Caso de estudio
Figura 11. Caso de Estudio
El diagrama anterior ilustra a grandes rasgos la porción de la cadena de suministro que se estudió
para validar el diseño. El proceso empieza con un cliente de Cartoflex, cuyo nombre no será
revelado por motivos de privacidad entonces se referirá a él como el consumidor. Este cliente le
envía una orden de producción a Cartoflex con las especificaciones y las cantidades de láminas
alveolares que necesita. Cuando Cartoflex recibe esa orden hace un pedido a su proveedor de
polipropileno. Este proveedor se dedica a la producción de bultos de polipropileno, asi que, al
recibir el pedido, le envía los bultos pedidos a Cartoflex por medio de un transportador. Cuando
el proveedor le entrega el pedido al transportador se firma un documento físico en el cual el
transportador certifica que recibió el pedido. Adicionalmente, se entregan algunos certificados
expedidos por el proveedor que garantizan la calidad y las especificaciones del producto. Cuando
el transportador llega a la fábrica de Cartoflex hace entrega de los bultos y los certificados, y
Cartoflex firma un documento para certificar que recibió el pedido.
Una vez Cartoflex recibe los bultos de polipropileno los registra en su sistema de inventario. El
software que utiliza para esto es World Office. Tras inventariar los insumos recibidos, se empieza
el proceso de extrusión en el cual se transforma el polipropileno recibido en las láminas
alveolares. Cuando se acaba el proceso de extrusión el resultado es un lote de producción el cual
es un conjunto de aproximadamente 120000 láminas. Este concepto de lote tambien es ingresado
al sistema de inventario. Después de la extrusión Cartoflex debe empezar a despachar diariamente
paquetes de láminas, pero antes de esto las láminas pasan por una serie de procesos manuales que
son: el troquelado, el perforado, el sellado y finalmente el empaquetado. Para el empaquetado se
necesitan bolsas industriales y un material llamado stretch. Para cada uno de estos insumos
Cartoflex cuenta con proveedores que le suministran las cantidades que necesita periódicamente.
Una vez se tienen los paquetes listos para despachar, estos se registran en el sistema contable y
se entregan a un transportador. Con este transportador nuevamente se maneja el sistema de
documentos para certificar la transferencia de los activos. Este transportador le lleva los paquetes
a otro actor denominado canvan. El canvan se encarga de almacenar las láminas producidas por
Cartoflex para que eventualmente el cliente las recoja en esa bodega y haga uso de ellas. Después
de que el cliente recoge las láminas suceden otros procesos posteriores que tambien hacen parte
de una cadena de suministro, pero para el propósito de este proyecto se limitó el proceso hasta el
momento en que se entregan al canvan ya que es la parte del proceso que concierne a Cartoflex y
sobre el cual se tiene total conocimiento.
En el diagrama de la figura 11 se puede evidenciar que se tienen 8 actores que son: el Productor
de polipropileno, el Productor de bolsas, el Productor de stretch, Cartoflex, el transportador, el
canvan y el cliente. Los 3 primeros actores podrían clasificarse como productores dentro del
diseño propuesto ya que el rol que cumplen en la cadena de suministro planteada es producir los
activos más primitivos de la cadena, estos siendo, los bultos de polipropileno, las bolsas y el
stretch. Cartoflex por su lado clasificaría como un transformador, ya que transforma los insumos
recibidos en láminas alveolares. El transportador, evidentemente sería clasificado como un
transportador ya que transporta activos a diferentes ubicaciones geográficas. Por otro lado, el
canvan entraría en la clasificación de distribuidor ya que no altera el estado de los activos, sino
que solo los almacena por un periodo de tiempo, y por último el cliente de Cartoflex se clasificaría
como el consumidor de esta pequeña cadena de suministro ya que es el que se queda con el activo
por un periodo indeterminado. Esto muestra que los 6 tipos de actores definidos en nuestra
arquitectura fueron suficientes para clasificar a los actores del caso de estudio.
En el proceso descrito tambien se puede destacar que cada vez que se transfieren los activos de
un actor a otro se cuenta con mecanismos no digitales para registrar dicha transferencia, lo cual
en el diseño propuesto se vería reflejado como la creación de una transacción. Por último, los
procesos se podrían modelar como actividades en el sistema. El productor haría periódicamente
actividades de tipo Producir en la que se producirían TRUs correspondientes a los bultos de
polipropileno. El transportador registraría su operación como actividades de tipo transportar tanto
a la hora de llevarlos a Cartoflex como a la hora de llevarlos al Canvan. Cartoflex tendría que
registrar actividades de tipo transformar por cada uno de los procesos que realiza internamente,
es decir, la extrusión, el troquelado, las perforaciones, el sellado y el empaquetado.
Alternativamente, Cartoflex podría solo reportar una sola transformación que encapsule todo el
proceso y que solo consuma los TRUs correspondientes a los insumos recibidos y produzca los
TRUs correspondientes a los paquetes despachados. El canvan no registraría ninguna actividad
en el sistema, solo aceptaría las transacciones. Y el cliente debería registrar una actividad de tipo
consumir a la hora de recoger la laminas del canvan. Todo el modelado anteriormente descrito se
muestra en la siguiente imagen.
Figura 12. Caso de Estudio Modelado
5.2 Escenarios de Despliegue Con el caso de estudio descrito en la sección anterior se pueden dar diferentes escenarios de
despliegue dependiendo del número de actores que decidan participar en el BCS y los recursos
que tengan cada uno de ellos. Como el propósito del sistema propuesto es que se pueda adaptar
a diferentes condiciones se documentaron diferentes escenarios de solución y cómo se daría el
despliegue del sistema en cada uno de esos escenarios. Los escenarios están ordenados del más
simple al más complejo y costoso.
5.2.1 Escenario 1
Figura 13. Escenario 1
En este primer escenario solo contamos con 2 actores, Cartoflex y el productor de polipropileno.
Este escenario podría darse si el pacto de implementar y usar el sistema se da solo entre estos 2
actores con el propósito de monitorear las interacciones entre ellos. En este escenario cada uno
debe contar con por lo menos un servidor para desplegar su aplicación, y su peer
correspondiente. Adicionalmente debe haber un orderer.
5.2.2 Escenario 2
Figura 14. Escenario 2
En este escenario se introduce un nuevo actor que quiere participar en la cadena, en este caso el
transportador. Sin embargo, se asume que dicho actor no cuenta con los recursos para montar un
servidor y una infraestructura propia. Por esta razon, usará la infraestructura de Cartoflex para
acceder al Blockchain y reportar su operación. Al hacer esto el CA1 cobra una mayor
importancia ya que es el componente encargado de diferenciar cuales transacciones fueron
hecha por Caroflex y cuales fueron hechas por el Transportador. Esta configuración permite que
los 3 actores tengan la posibilidad de registrar y consultar informacion del Blockchain, sin
embargo, el transportador no queda en igualdad de condiciones porque tiene que confiar en la
aplicación y en la infraestructura de Cartoflex, y no tiene la posibilidad de verificar las
transacciones de los demas.
5.2.3 Escenario 3
Figura 15. Escenario 3
Este escenario es una posible configuración de despliegue en la cual participan los 8 actores que
hay en el caso de estudio planteado. Como se puede ver solo 4 de ellos tienen la capacidad de
tener infraestructura propia y los demas actores deben usar infraestructura ajena. Este no es el
escenario más complejo, ni el más ideal ya que el escenario ideal es en el que cada actor cuenta
con su propia infraestructura. Sin embargo, ese caso es demasiado costoso, por eso escenarios
de este tipo se consideran mucho más realistas y viables.
6. Implementación
6.1 Descripción de la implementación Con base a los escenarios planteados en la sección anterior, se escogió el escenario 1 para el
prototipo construido. En este escenario solo contamos con 2 actores, el Productor de polipropileno
y Cartoflex. Entonces para el prototipo se asumió que solo esos 2 actores participan en la red.
Además, por simplicidad se tomó la decisión de que Cartoflex no va a registrar cada uno de sus
procesos internos sino solo los más relevantes, estos siendo la Extrusión y el empaquetado. Esto
se hizo por 2 principales razones. La primera es que esos son los 2 procesos que ellos actualmente
registran en su sistema contable y como la intensión es que el uso del nuevo sistema no genere
cargas adicionales en los procesos, lo más realista es asumir que la empresa solo estaría dispuesta
a registrar en el nuevo sistema los 2 procesos que ya están acostumbrados a registrar en un sistema
digital. La segunda razon era mostrar que una empresa no tiene que reportar todo el detalle de su
operación en la red, sino solo los procesos más importantes que muestran cómo se transforman
los activos en su interior. De esta forma mostramos que el modelaje propuesto se adapta a
cualquier nivel de detalle que la empresa desee registrar.
El prototipo implementado entonces consistió en el desarrollo del componente back-end API y 2
aplicaciones web, una para el productor, y una para Cartoflex. Estas aplicaciones consumen el
API para agregar información al Blockchain y asi cumplir con los requerimientos RF3 y RF4.
Adicionalmente, ambos clientes web cuentan con una visualización que les permite consultar el
comportamiento de cualquier activo que haya sido persistido en el sistema y explorar el
comportamiento que este ha tenido en la cadena de valor. Con dicha visualización se cumple con
los requerimientos RF1 y RF2. El código fuente del prototipo puede ser encontrado en
https://github.com/mateodevia/BlockChainTracebility.
6.1.1 API El servidor web que expone el API se implementó usando Node JS con el framework Express JS.
Dicho servidor expone servicios de tipo REST que permiten ejecutar los smart contracts de la red.
Es importante resaltar que el API ofrece 3 mecanismos para identificar TRUs de forma única. La
primera él es id_tru que es un identificador único que crea el sistema cuando se producen TRUs.
Este id es el id de la actividad que creo al TRU seguido de ‘-’ y finalmente un entero único para
el TRU. El segundo identificador es el Universal Product Code (UPC) el cual es el código presente
en los códigos de barra que tiene los productos, y que es un estándar a nivel mundial. Por último,
se tiene el Stock Keeping Unit (SKU), el cual es un código que asignan las empresas a los activos
cuando los ingresan a su sistema de inventario. Como este número lo coloca arbitrariamente cada
empresa, no hay forma de garantizar que un SKU sea único en la cadena de suministro, por lo que
para identificar un TRU de manera única con el SKU tambien se debe especificar el actor que
asignó ese SKU. Otra cosa a resaltar del API es que este no expone servicios para crear TRUs. La
razon para esto es que los TRUs siempre se crean a través de la creación de una actividad. A
continuación, se muestra una breve documentación del API.
GET /trus/id/{id_tru}
Retorna un documento con el estado actual del TRU identificado con el
id_tru recibido por parámetro.
GET /trus/upc/{upc}
Retorna un documento con el estado actual del TRU más reciente que tenga
el código UPC recibido por parámetro.
GET /actores/{actor}/trus/{sku}
Retorna un documento con el estado actual del TRU más reciente que tenga
el SKU recibido por parámetro asignado por el actor recibido por
parámetro.
GET /trus/id/{id_tru}/origen
Retorna la lista de actividades que fueron necesarias para crear el TRU
identificado con el id_tru recibido por parámetro.
GET /trus/id/{id_tru}/destino
Retorna la lista de actividades que se dieron posteriores a la creación
del TRU identificado con el id_tru recibido por parámetro, y que
involucraron a dicho TRU o a cualquier TRU derivado de él.
GET /trus/upc/{upc}/origen
Retorna la lista de actividades que fueron necesarias para crear el TRU
más reciente que tenga el código UPC recibido por parámetro.
GET /trus/upc/{upc}/destino
Retorna la lista de actividades que se dieron posteriores a la creación
del TRU más reciente que tenga el código UPC recibido por parámetro, y
que involucraron a dicho TRU o a cualquier TRU derivado de él.
GET /actores/{actor}/trus/{sku}/origen
Retorna la lista de actividades que fueron necesarias para crear el TRU
más reciente que tenga el SKU recibido por parámetro asignado por el
actor recibido por parámetro.
GET /actores/{actor}/trus/{sku}/destino
Retorna la lista de actividades que se dieron posteriores a la creación
del TRU más reciente que tenga el SKU recibido por parámetro asignado
por el actor recibido por parámetro, y que involucraron a dicho TRU o a
cualquier TRU derivado de él.
POST /actores
Crea un actor para la cadena de suministro.
Ejemplo de body:
{
"nombre": "Cartoflex",
"identificacion": "8004541640-0",
"tipo": "TRANSFORMADOR"
}
POST /transacciones
Crea una transaccion entre 2 actores de la cadena
Ejemplo de body:
{
"trus": [
"efa91e20-7413-11ea-9fdf-2174e1b0eb66-0",
"efa91e20-7413-11ea-9fdf-2174e1b0eb66-1"
],
"fuente": "Productor",
"destino": "Transportador",
"fecha": "2020-04-01T19:29:31.982Z"
}
POST /actividades/producir
Crea una actividad de tipo producir.
Ejemplo de body:
{
"trus": [
{
"nombre": "Homopolimero",
"indice de fluides": "90%",
"cantidad": "5Kg",
"SKU": "12345",
"UPC": "12345"
},
{
"nombre": "Copolimero",
"indice de fluides": "95%",
"cantidad": "5Kg",
"SKU": "56789",
"UPC": "12345"
}
],
"actor": "Productor",
"ubicacion": {
"lat": 10.0,
"lon": 11.0
}
}
POST /actividades/transformar
Crea una actividad de tipo transformar.
Ejemplo de body:
{
"trus_consumidos": [
"d3da62f0-744d-11ea-abce-1b474a67a6e2-1"
],
"trus_producidos": [
{
"cliente": "Cliente 1",
"cantidad": "3kg",
"producto": "PANEL ANDROMEDA 300 L VENTANA",
"REFERENCIA": "294D1747P003",
"dimension": "558*1454",
"codigo": "PTL2GR032-29"
},
{
"cliente": "Cliente 1",
"cantidad": "5kg",
"producto": "PANEL ANDROMEDA 300 L VENTANA",
"REFERENCIA": "294D1747P003",
"dimension": "558*1454",
"codigo": "PTL2GR032-29"
}
],
"actor": "Cartoflex",
"ubicacion": {
"lat": 10.0,
"lon": 11.0
}
}
POST /actividades/transportar
Crea una actividad de tipo transportar.
Ejemplo de body:
{
"trus": [
"efa91e20-7413-11ea-9fdf-2174e1b0eb66-0",
"efa91e20-7413-11ea-9fdf-2174e1b0eb66-1"
],
"destino": {
"lat": 75.5,
"lon": -73.12
}
}
POST /actividades/invalidar
Crea una actividad de tipo invalidar.
Ejemplo de body:
{
"trus": [
{
"id": "010ff4d0-6c5e-11ea-a247-67287ceabe54-1",
"razon": "Se venció la fecha de caducidad",
"certificacion": {
"url": "www.foto.com"
}
}
],
"ubicacion": {
"lat": 10.0,
"lon": 11.0
}
}
POST /actividades/consumir
Crea una actividad de tipo consumir.
Ejemplo de body:
{
"trus": [
"efa91e20-7413-11ea-9fdf-2174e1b0eb66-0"
],
"ubicacion": {
"lat": 74.5,
"lon": -73.12
}
}
6.1.2 Visualización Para el diseño de la visualización se empezó por definir las tareas que el usuario debe ser capaz
de hacer al consultar la visualización, las cuales están fuertemente relacionadas con los
requerimientos RF1 y RF2. Dichas tareas se muestran a continuación.
Tarea 1
Determinar el estado de un activo en un momento del tiempo
Tarea 2
Determinar todos los procesos que ocurrieron en la cadena de suministro para que un activo
estuviese en un estado determinado en un momento del tiempo determinado.
Tarea 3
Determinar todos los procesos que ocurrieron en la cadena de suministro a partir de la existencia
de un activo en un momento determinado.
A partir de estas 3 tareas se diseñó una visualización en React JS en forma de grafo cuyos nodos
representan las distintas entidades registradas en el blockchain. Los nodos en forma de rectángulo
representaran las actividades, los nodos en forma de rombo representan las transacciones, y los
círculos representan los TRUs. En la visualización el eje Y representa el tiempo. Los nodos que
se encuentran más arriba son los registros que ocurrieron más atrás en el tiempo mientras que los
que están más abajo son los más recientes. En otras palabras, el grafo esta ordenado verticalmente
en orden cronológico. Por último, los colores de los nodos indican el actor que realizo la actividad,
o el dueño del TRU. Por esta razon los nodos de transaccion son de color blanco y generan un
cambio de color ya que son un cambio en la custodia de los TRUs. A continuación, se muestra
una imagen con el resultado final de la visualización para la consulta de origen.
Figura 16. Visualización del Origen
En esta primera imagen se muestra un grafo simplificado para el caso de estudio de Cartoflex.
Es el resultado de consultar el origen del TRU 3668dc40-7457-11ea-abce-1b474a67a6e2-0 el
cual está representado en la visualización por el circulo de mayor tamaño que se encuentra en la
parte inferior del grafo. Se encuentra en la parte inferior porque todos los otros eventos que se
muestran en el grafo son eventos que ocurrieron previamente en el tiempo. Ahora se explicará
en detalle el significado de cada elemento del grafo.
Figura 17. TRU buscado
En esta primera parte del grafo se muestra el TRU que busco el usuario. El cual en su momento
de creación le pertenecía al actor denominado Transportador y por eso es de color morado. Sin
embargo, el rombo que tiene abajo simboliza que posterior a su creación estuvo involucrado en
una transaccion. Por otro lado, se puede ver que este TRU proviene de una actividad de tipo
transportar la cual tambien fue realizada por el transportador y por eso es de color morada.
Figura 18. Actividad de Transformar
En la figura 18 se muestra que la actividad de transporte consumió 2 TRUs que son los que
aparecen de color verde. Sin embargo, antes de realizar la actividad de transportar fue necesario
que hubiera 2 transacciones para que el transportador adquiriera la custodia de dichos TRUs.
Estas 2 transacciones están representadas por los rombos blancos. Tambien se puede apreciar
que los 2 TRUs en cuestión le pertenecían a Cartoflex en el momento de su creación porque son
de color verde. Por último, se puede ver que los TRUs vienen de una actividad de tipo
transformar que fue realizada por Cartoflex.
Figura 19. Actividades deTransformar, Transportar y Producir
En la figura 19 vemos que anteriormente a eso hubo otra transformación por parte de Cartoflex
y antes de eso otra actividad de tipo Transportar por parte del transformador. Finalmente vemos
que el origen del TRU buscado fue una actividad de tipo producir por parte del productor en la
cual se produjeron 4 TRUs.
Aunque el grafo es útil para ver el flujo de eventos y las relaciones que hay entre las actividades
y los TRUs no es fácil entender qué tipo de TRU es cada uno. Es por esto se agregó una
funcionalidad adicional la cual permite que al hacer click sobre cualquier nodo en el lado
derecho de la pantalla aparece la información detallada del nodo seleccionado tal como se
muestra en la figura 20.
Figura 20. Detalle de un TRU
En la imagen se ve que salen todas las características del activo que se encuentra resaltado en
rojo. Vemos que las características pueden ser tanto imágenes como mapas interactivos de
Google Maps. El prototipo implementado tambien permite montar videos de Youtube y verlos
dentro de la página. Con esta nueva informacion se ve más claramente que el activo
representado por ese círculo es un paquete de los que despacha Cartoflex diariamente. De igual
manera tambien se puede ver el detalle de las actividades y de las transacciones como se
muestra en las 2 siguientes imágenes.
Figura 21. Detalle de una actividad
Ilustración 22. Detalle de una Transacción
En cuanto a la consulta de destino, la visualización tambien muestran un grafo con las mismas
representaciones, la única diferencia es que como esta consulta muestra eventos posteriores, el
TRU buscado se muestra en la parte superior como se puede ver en la siguiente imagen.
Ilustración 23. Visualizacion del destino
Esta imagen muestra el resultado de la consulta de destino sobre los mismos datos que en las
imágenes anteriores, pero en este caso se realizó la consulta sobre el TRU efa91e20-7413-11ea-
9fdf-2174e1b0eb66-0 el cual es uno de los bultos producidos por el productor al comienzo.
6.1.3 Aplicaciones Cliente Las aplicaciones que se implementaron como 2 aplicaciones web en React JS que son servidas
estáticamente por el servidor que expone el API. La aplicación del productor tiene 2
funcionalidades principales además de tener acceso a la visualización ilustrada en la sección
anterior. La primera funcionalidad es la que le permite al productor registrar su actividad de
producir activos. La interfaz permite ingresar las características de los distintos TRUs que se
crearon en la actividad que va a reportar en la red como se puede ver en la figura 24. La segunda
funcionalidad es crear una transaccion en la cual ingresan los identificadores de los TRUs que
se quiere transferir y se escoge el nombre del actor de la red a la cual se quiere transferir como
se muestra en la figura 25.
Figura 24. Registro de actividad de producir
Figura 25. Registro de transaccion del Productor
En cuanto a la aplicación de Cartoflex, tambien cuenta con 2 funcionalidades principales. La
primera es poder registrar la transformación de un conjunto de TRUs y especificar las
características de los TRUs producidos por la transformación como se ilustra en la figura 26.
Por último, la figura 27 muestra que desde la aplicación implementada para Cartoflex tambien
se puede generar una transaccion hacia otro actor de la cadena igual que como se hace en la
aplicación del productor.
Figura 26. Registrar actividad de transformar
Ilustración 27. Registrar transaccion de Cartoflex
6.2 Resultado de la implementación
6.2.1 Despliegue Para el despliegue de la aplicación se utilizó la infraestructura de Microsoft Azure que se
consiguió con la membrecía educativa. El despliegue se hizo para modelar el escenario 1 y
respetando las especificaciones dadas en la figura 9.
Para simular un ambiente real se agregaron datos ficticios correspondientes a los datos que se
esperaría tener tras un año de producción en el dominio de Cartoflex. La estimación de estas
cifras se realizó con la ayuda de Santiago Vargas el director financiero de Cartoflex y se
estimaron de la siguiente manera.
Cartoflex maneja ciclos de producción mensuales. Cada mes realiza pedidos al Productor de
polipropileno de aproximadamente 14400kg de polipropileno lo que es equivalente a 176 bultos
de 25kg. Con estos insumos, Cartoflex realiza un solo proceso de extrusión en el cual
transforma los 14400kg de polipropileno en un lote de aproximadamente 120000 láminas.
Después del proceso de extrusión se empiezan a hacer despachos diarios. Cada día se despachan
aproximadamente 80 paquetes de 50 láminas. En los términos definidos en la arquitectura
propuesta esto se modelaría de la siguiente manera.
- Actividad de tipo Producir (mensual):
o En la que el productor produce 576 TRUs que representan los 576 bultos que
necesita Cartoflex.
- Transacción (mensual):
o En la que el productor le transfiere los 576 TRUs a Cartoflex
- Actividad de tipo Transformar (mensual):
o En la que se representa el proceso de extrusión y se produce un TRU que
representa el lote de laminas
- Actividad de tipo Transformación (diaria):
o En la se producen 80 TRUs que representan los 80 paquetes despachados cada
día.
Estos datos se cargaron al sistema con ayuda de un script que simula el proceso anteriormente
descrito consumiendo los servicios expuestos con el API. Al finalizar la carga de datos, la base
de datos de estado quedó con un total de 81.1MB de almacenamiento correspondientes a 65806
documentos persistidos.
6.2.2 Pruebas de Carga Para probar el desempeño de la arquitectura propuesta se realizaron unas pruebas de carga sobre
el sistema desplegado con la base de datos poblada como se describió en la sección anterior. Las
pruebas de carga se hicieron en periodos de 60 segundos en las que se simulaban un determinado
número de usuarios concurrentes que hacían peticiones a los servicios del API. El número de
usuarios concurrentes se fue aumentando para ver el comportamiento de los tiempos de respuesta
al incrementar el número de usuarios concurrentes. Adicionalmente se llevó un registro del
número de peticiones que se lograron atender en los 60 segundos que duró cada prueba. Las
pruebas se realizaron usando la herramienta K6 [14] y los resultados se muestran a continuación.
6.2.2.1 Resultados para la consulta de origen
Número de
usuarios
concurrentes
Número de
peticiones
atendidas
Tiempo
promedio de
respuesta (ms)
Tiempo mínimo de
respuesta (ms)
Tiempo máximo de
respuesta (ms)
10 2305 258,58 162,56 527,7
20 3054 389,98 169,62 743,03
30 3179 562,55 170,54 1540
40 3304 718,77 183,51 1080
50 3473 853,78 479,79 1850
100 3672 1610 661,73 2250
200 3629 3220 447,78 6540
300 3580 4820 857,7 8050
400 3544 6320 705,62 9800
500 3580 7890 522,6 12180
600 3325 9640 676,19 15780
700 3212 11420 1010 18540
800 3330 12810 705,11 20660
900 3101 15080 806,93 21140
1000 3252 16050 1020 24450
1250 2839 21640 1270 30870
1500 3173 25480 1430 33820
1750 2556 29420 1660 42230
2000 2121 35820 2460 39430
Tabla 4. Resultados consulta origen
Figura 28. Resultados tiempos consulta origen
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
Tiem
po
de
resp
ues
ta (
s)
Numero de usuarios concurrentes
Consultar el origen
avg time min time max time
Figura 29. Resultados peticiones consulta origen
6.2.2.2 Resultados de la consulta de destino
Número de
usuarios
concurrentes
Número de
peticiones
atendidas
Tiempo
promedio de
respuesta (ms)
Tiempo mínimo de
respuesta (ms)
Tiempo máximo de
respuesta (ms)
10 3060 194,99 148,6 434,85
20 4952 240,67 146,6 237,36
30 6233 286,98 148,6 746,37
40 5809 409,4 150,61 835,95
50 6003 494,89 153,58 1120
100 6915 860,49 164,56 2260
200 7483 1580 319,2 2820
300 7320 2380 172,54 4640
400 7320 3190 395,11 6380
500 7249 4010 506,69 7710
600 7112 4820 633,45 11640
700 7080 5590 946,46 10190
800 6807 6610 732,03 13160
900 6931 7240 925,66 13340
1000 6678 8290 975,39 16930
1250 6467 8890 1250 22010
1500 6540 12430 1370 22580
1750 5897 15400 1690 25960
2000 5329 19010 1410 30930
2250 5701 21480 1370 37590
2500 5703 20880 1830 42610
Tabla 5. Resultados consulta destino
0
500
1000
1500
2000
2500
3000
3500
4000
0 500 1000 1500 2000 2500
Nu
mer
o d
e p
etic
ion
es a
ten
did
as
Numero de usuarios concurrentes
Numero de peticiones atendidas
Figura 30. Resultados tiempos consulta destino
Figura 31. Resultados peticiones consulta destino
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
10
20
30
40
50
10
0
20
0
30
0
40
0
50
0
60
0
70
0
80
0
90
0
10
00
12
50
15
00
17
50
20
00
22
50
25
00
Tiem
po
de
resp
ues
ta (
s)
Numero de usuarios concurrentes
Consultar Destino
avg time min time max time
0
1000
2000
3000
4000
5000
6000
7000
8000
0 500 1000 1500 2000 2500 3000
Nu
mer
o d
e p
etic
ion
es a
ten
did
as
Numero de usuarios concurrentes
Numero de peticiones atendidas
6.2.2.3Resultados al crear una actividad
Número de
usuarios
concurrentes
Número de
peticiones
atendidas
Tiempo
promedio de
respuesta (ms)
Tiempo mínimo
de respuesta (ms)
Tiempo máximo de
respuesta (ms)
10 890 670,03 548,53 2320
50 1680 1760 864,82 3,69
100 1470 3940 2340 4860
200 1541 7150 4110 7068
300 1291 12310 4600 20060
400 1380 15150 6160 21110
500 1220 20720 8400 30720
600 1291 22590 7870 36140
700 880 33670 7750 49680
800 1081 28710 7080 48980
900 801 39960 7150 59450
Tabla 6 Resultados crear actividad
Figura 32. Resultados tiempos crear actividad
0
10000
20000
30000
40000
50000
60000
70000
10 50 100 200 300 400 500 600 700 800 900
Tiem
po
s d
e re
spu
esta
(s)
Numero de Usuarios concurrentes
Crear Actividad
avg time min time max time
Figura 33. Resultados peticiones crear actividad
6.2.2.4 Resultados al crear una transaccion
Número de
usuarios
concurrentes
Número de
peticiones
atendidas
Tiempo
promedio de
respuesta (ms)
Tiempo mínimo
de respuesta (ms)
Tiempo máximo de
respuesta (ms)
10 460 642,83 45,78 1570
50 893 1640 778 5230
100 890 3000 1490 5390
200 840 6120 3850 10750
300 670 10540 6620 17700
400 800 12710 6170 22540
500 542 16650 4270 25400
600 632 19920 5800 32340
700 663 22600 7860 38990
800 190 35900 2640 55850
900 360 31360 7580 56120
1000 24 41910 7640 58030
Tabla 7. Resultados crear trasacción
0
200
400
600
800
1000
1200
1400
1600
1800
0 200 400 600 800 1000
Nu
mer
o d
e p
etic
ion
es a
ten
did
as
Numero de usuarios concurrentes
Numero de peticiones atendidas
Figura 34. Resultados tiempos crear transacción
Figura 35. Resultados peticiones crear transacción
De los resultados se quiere destacar que la arquitectura propuesta soporta un gran número de
usuarios concurrentes sin generar errores. En general las peticiones soportan alrededor de 1000
usuarios concurrentes sin empezar a fallar, lo cual es muy superior al número de usuarios que se
esperaría tener concurrentemente en un sistema como este. Sin embargo, los tiempos de
respuesta con esta cantidad de usuarios concurrentes no son aceptables. Para un sistema de estos
la latencia no es un atributo de calidad fundamental, sin embargo, un tiempo de respuesta
aceptable no debería superar los 15 segundos. En promedio, este tiempo se da entre los 100 y
200 usuarios concurrentes.
0
10000
20000
30000
40000
50000
60000
70000
10 50 100 200 300 400 500 600 700 800 900 1000
Nu
mer
o d
e p
etic
ion
es a
ten
did
as
Numero de usuarios concurrentes
Crear Transacción
avg time min time max time
0
100
200
300
400
500
600
700
800
900
1000
0 200 400 600 800 1000 1200
Nu
mer
o d
e p
etic
ion
es a
ten
did
as
Numero de usuarios concurrentes
Numero de peticiones atendidas
7. Conclusiones De manera general se concluye que se cumplió con los objetivos del proyecto ya que se logró
implementar un prototipo que cumple con los requerimientos funcionales y no funcionales
plateados. La validación con el caso de estudio mostró que el diseño planteado tiene suficiente
flexibilidad para adaptarse a una industria como la de Cartoflex, sin embargo, es necesario
probar el diseño en otros dominios. El prototipo tambien mostro soportar una alta carga de
trabajo, sin embargo, los tiempos de respuesta son altos en comparación a lo que ofrecen otros
sistemas hoy en día, lo cual era algo que se esperaba al usar la tecnología Blockchain.
7.1 Discusión de los resultados Con la validación del diseño en el caso de estudio propuesto se confirmó que el modelo planteado
para una cadena de suministro es adecuado ya que nos permitió modelar el caso de estudio y
además nos permitió escoger libremente el nivel de detalle que se quería manejar. Sin embargo,
al usar la visualización se detectó un problema en la trazabilidad en las actividades de tipo
transportar. En esta actividad la relación de TRUs consumidos y TRUs producidos es uno a uno.
Es decir, por cada TRU consumido por una actividad de este tipo se debe producir un TRU
correspondiente ya que esencialmente representan el mismo activo físico solo que en otra
ubicación y posiblemente con características un poco diferentes. Con el modelo planteado, esto
se cumple, sin embargo, no hay forma de saber cuál de los TRUs consumidos corresponde a cada
uno de los TRUs producidos. En la figura 28 podemos ver que el activo resaltado en color rojo
fue producido por una actividad de tipo transportar la cual transportó los 4 TRUs resaltados en
color azul. Sin embargo, es imposible determinar cuál de los 4 TRUs originales corresponden al
TRU resaltado en rojo. En el caso de estudio de Cartoflex era posible determinar esto a partir de
los SKUs y el código UPC, pero puede no ser el caso en otra cadena de suministro que no manejen
estos identificadores.
Ilustración 36. Trazabilidad de la actividad transformar
Por otro lado, al implementar la visualización y las aplicaciones clientes del sistema se pudo
validar el diseño del API desde el punto de vista de un desarrollador. Incluso durante el proceso
se realizaron algunas mejoras al API y al modelo de datos, las cuales mejoraron la usabilidad
del API. En general, se puede concluir que el API cumple con su propósito ya que nunca limitó
el desarrollo de las aplicaciones o de la visualización. Sin embargo, es importante resaltar que si
se presentaron dificultades a la hora de mapear los resultados de las consultas de origen y
destino a la visualización. Esta dificultad se dio más que todo porque la estructura de datos que
se está representando es un grafo y el resultado de las consultas se da en forma de lista. De
cualquier forma, con un poco de algorítmica en la capa de presentación se logró el objetivo y la
visualización muestra el grafo correctamente.
En cuanto a los resultados de las pruebas de carga se estima que la arquitectura planteada
soporta un máximo de 100 usuarios concurrentes antes de empezar a degradar la calidad del
servicio. Dada la naturaleza del negocio, esta es una métrica aceptable para cumplir las
necesidades de una cadena de valor ya la cantidad de transacciones diarias que realiza cada
actor es bastante pequeña. Por ejemplo, en el caso de estudio propuesto, cada actor realiza un
máximo de 2 peticiones diarias y estas no eran concurrentes ya que como representan un
proceso se dan una después de otra. Sin embargo, con otro caso de estudio un poco más amplio
y masivo sí podrían darse transacciones concurrentes. Por otro lado, el número de actores en una
cadena de suministro no se espera que sea superior a 100 lo que minimiza la posibilidad de que
en algún momento se generen 100 transacciones concurrentes. Por ende, se concluye que los
resultados de desempeño obtenidos son satisfactorios, aunque existen tácticas de arquitectura
que podrían mejorar la escalabilidad del sistema.
7.2 Trabajo Futuro Aunque se logró cumplir con los objetivos y el alcance planteado para el proyecto, existen muchas
validaciones y alternativas a probar antes de que un sistema como el propuesto pueda ponerse en
producción. A continuación, se proponen algunas ideas de cómo se podría continuar y mejorar el
trabajo realizado en este proyecto de grado:
- Replantear el modelado de la actividad de tipo transportar para solucionar los problemas
de trazabilidad encontrados.
- Desarrollar prototipos para los otros escenarios planteados para el caso de estudio.
- Encontrar otros casos de estudio más amplios y complejos que permitan validar a mayor
profundidad el diseño propuesto.
- Intentar integrar sistemas ya existentes (como ERPs o sistemas contables) con el API
propuesto para validar la adaptabilidad del API de mejor manera.
- Explorar otras alternativas para exponer los servicios del API, como por ejemplo el
desarrollo de un API GraphQL lo cual podría mejorar mucho la adaptabilidad del API ya
que permite al consumidor del API definir la estructura de datos, lo que ayudaría a
representar el grafo en una manera más coherente.
- Desarrollar un prototipo que use LevelDB como base de datos de estado, ya que según la
literatura esto mejora el desempeño del sistema.
- Desarrollar un prototipo que use Go como lenguaje para los smart contracts, ya que según
la literatura esto mejora el desempeño del sistema.
- Desarrollar un proyecto que permita poner el prototipo en un ambiente de producción real
para evaluar los beneficios que trae el sistema propuesto a una industria real.
8. Referencias
[1] Buy Bitcoin. 2020. How Many Bitcoin Users Are There? Szmigiera. 2020. Number of
Blockchain wallets
https://www.statista.com/statistics/647374/worldwide-blockchain-wallet-users/
[2] Shuian Wang, Xiabo Qu. 2019. Blockchain Applications in Shipping, Transportation,
Logistics, and Supply Chain. Recuperado en Feb 2020.
[3] Petri Helo, Yuqiuge Hao. 2019. Blockchain in operations and supply chains: A model and
reference implementation. Recuperado en Feb 2020.
[4] Mann Suruchi, Vidyasagar, Raj Shekhar, Anulip Chandan. 2018. Blockchain Tecnology for
Supply Chain Traceability, Transparency, and Data Provenance. Recuperado en Fed 2020.
[5] Henry M. Kim, Marek Laskowski. 2018. Toward an Ontology-driven blockchain design for
supply -chain provenance. Recuperado en Feb 2020.
[6] Saungen Kim, Dongsoo Kim. Design of an innovative blood cold chain management system
using blockchain technologies. 2018. Recuperado en Feb 2020.
[7] T Senthil Kumar, S. Prabakaran, Ashim Sharma, Devvrat Vaidya. 2019. Smart Blood
Management and Tracking System. Recuperado en Feb 2020.
[8] Diego Riveros, Gabriel Martinez, Juan Diego Gonzales, Nicolas Cabrera. 2019. Diseño e
implementación de tecnologías Blockchain para el sector salud en Colombia. Recuperado en
Feb 2020.
[9] Universidad de los Andes. 2019. Conceptos Básicos de Blockchain. Presentación presentada
en reunión con representantes del Laboratorio Blockchain.
[10] The Linux Foundation. 2020. Hyperledger. Recuperado de https://www.hyperledger.org/
[11] Etherium. 2020. Developer Resouces. Recuperado de https://ethereum.org/.
[12] Hyperledger. 2020. Hyperledger Fabric. Recuperado de
https://hyperledger-fabric.readthedocs.io/en/latest/prereqs.html.
[13] Hyperledger. 2020. Tutorials. Recuperado de
https://hyperledger-fabric.readthedocs.io/en/release-1.4/tutorials.html
[14] K6. 2020. K6 docs. Recuperado de
https://hyperledger-fabric.readthedocs.io/en/latest/prereqs.html
