Frequently Asked Questions
ARXUM is based on German Industry 4.0 expertise and will have a strong footprint in the German market. But the company will be established in Switzerland and the business will be managed and driven form Switzerland.
ARXUM provides a Production Protocol. We connect several peers who produce something together. There is a buyer and several providers. There are also people who ship between assemblers and buyers. We provide a new way of manufacturing based on smart contracts. This brings peers together as they all receive documents, info and data that they need before, and during, the manufacturing process, as well as after it. Based on this, we have 3 main applications which can be built upon the ARXUM Production Protocol:
1: A marketplace. Someone looks for manufacturing possibilities and someone provides manufacturing capacities. This creates a market place. Just as Amazon, where people seeking stuff and people offering stuff are brought together. ARXUM can implement a marketplace in the same way for manufacturing capacity. The execution is done by the ARXUM Protocol.
2: A Production Consortium: ARXUM is beneficial to, for example, industrial manufacturers who have established relationships with suppliers. The manufacturers, by using the production protocol, can streamline their processes and gain enormous potential of benefits of not having to call, fax, negotiate, send emails, pass orders, create IT structures, contact suppliers etc... ARXUM does all of this for them; decentralized, with smart contracts. Thanks to ARXUM, these participants immediately get all the information they need, provided to their IT-Systems and can concentrate on their core business.
3: Mass-Customization: ARXUM’s new way of manufacturing can be used for mass customization. It can be applied to standard products. Right now, in order to create customized goods, one must convince manufacturers to change their processes. This takes an immense amount of time since customization requires fully horizontal digitalized processes. That is where ARXUM enters. With ARXUM, the projects are integrated on an IoT and Industry 4.0 level, meaning that machines are interconnected. Customization data is directly pushed into the right production machine. Now, customization is possible with the lowest time and effort and at almost no additional cost.
Anyone can use ARXUM. The location doesn’t matter.
ARXUM’s worldwide Production Protocol comprises a set of fundamental rules which govern the agreement on production orders between two or more partners in the ARXUM network.
The protocol consists of the following main components:
- An Ethereum smart contract for payment and escrow of funds.
- A Ricardian smart contract with bindings for all manufacturing partners.
- An off-chain secure storage for digital assets and rich context data.
As the ERC-20 AX token is used in the smart contract, all payment and settlement related activities are executed in Ethereum. In some cases this can be just one final payment.
All conditions relevant for fixing the ambiguities of a manufacturing process are stored in a Ricardian smart contract (RSC). The execution of this smart contract is generally implemented in a different technology, as e.g. Hyperledger. In order to seize the benefits of a blockchain implementation, such as proof-of-existence, proof-of-ownership and auditability of manufacturing progress, the Ethereum network is far too costly and higher transaction throughput is required.
For a manufacturing order it is imperative to provide specifications at a sufficient level of detail, e.g. in form of a computer aided design file or blueprint as a digital asset. This data is secure stored off-chain and only relevant parties of one contract/production order have access to their respective data.
There is a 1:1 relation between the Ethereum payment contract and the alternative ledger execution contract. The Ethereum contract can be used multiple times when similar production orders and RSCs are re-created and executed for "more of the same“ products.
ARXUM uses Ricardian smart contracts to bind all peers into one production order. In a Ricardian smart contract, additional data can be integrated in a way which is human readable and machine readable.
In this part of the smart contract, many conventions and conditions can be defined. These can be e.g.: legal documents, social standards, quality criteria, norms and standards, materials, and many more.
The Ricardian smart contracts allow integrating key-value pairs in a machine readable and human readable format. In a Ricardian smart contract, quality standards can be defined and the respective contractual partners are bound to adhere to the defined norms and standards.
These norms and standards can be:
- IATF 16949 (quality management in automotive sector),
- DIN EN ISO 286 (Tolerances),
- DIN EN ISO 14405 or ISO 2768-1 (measurement and angle tolerances),
- DIN EN ISO 1101 (form and position tolerances),
- DIN EN ISO 1302 (surface composition & quality), and others
or social standards, like:
- SA 8000 (Social Accountability 8000),
- ISO 26000 (sustainability),
- DIN Norm 33926 (ecological balance),
- ILO Work- and Social Standards, and many more
or other documents such as bi-lateral legal agreements and bindings.
Whether the standards and agreements are adhered to can partially be verified through inspection of the products, the workplaces or production facilities. The auditing process through state agencies or generally through the purchaser becomes an easy and simple task on the distributed ledger.
Physical quality standards have to be controlled through random samples upon delivery of the manufactured products. The decision of acceptance is integrated as a transaction in the smart contract leading to a liberation of funds and final payment of the manufacturer. Manufacturers can only assume to be fully paid when they adhere to all standards set forth in the smart contract.
The standards and agreements referred to in the Ricardian smart contract are safely stored off-chain.
Production orders are currently negotiation processes with a lot of manual interaction between the different peers: buyer, assembler, suppliers, transport agents and others. This currently requires a lot of manual interaction, communication and exchanges.
One smart contract, instantiated by a software factory, will set the boundary conditions for a class of products or a consortium of suppliers.
Instead of manually and sequentially passing through several different ERP systems, the smart contract is providing manufacturing data on the IoT machine level to the factories, simultaneously to all manufacturing peers.
Manufacturing of goods usually requires a lot of data files with specifications about the product and manufacturing conditions. This can be:
- schematics, blueprints or CAD files
- assembly instructions or process definitions
- configuration data, settings and adjustment data
- firmware and software
- keys, numbers, pass phrases or cryptographic data
- technical norms and standards
- non-technical norms and standards
- auxiliary data, like examples, proposals,
or live data provided by oracles such as:
- geolocation data
- weather data (e.g. for target regions of a product)
- and many more.
In a public marketplace, inventors and prosumers need to trust that their inventions (i.e. digital assets) are protected and will not be copied by unauthorized manufacturers. Because of this, the digital assets are primarily stored locally on the user’s computer.
All digital assets which need to be exchanged between parties are hashed. The hash is stored on a digital asset ledger with an attribution to its owner. Blockchain is used to protect the ownership of intellectual property.
Data is exchanged in an encrypted state and only accessible to partners who require access. Accessing data (the fact of decrypting an encrypted digital asset) is stored as a transactional event in the digital asset database.
For some data it is not useful to have it stored on a node which is not permanently available, when manufacturers have to rely on the availability of data. Particularly if this data is used by a larger number of manufacturers or manufacturing peers over a longer period of time. This can, for example, be legal agreements or framework contracts between manufacturers and suppliers, which have been negotiated and which are referenced in ARXUM’s Ricardian smart contracts. All smart contract peers are bound to these agreements and need perpetual access.
These documents are stored as encrypted files in a decentralized database, providing permanent availability but accessibility only to those with the required permissions, i.e. the contract key to decrypt these data files.
In the smart contract, you could include a laboratory that verifies product samples. You can for example say that one piece of what I produce is sent to a laboratory who creates a laboratory report. The results are immutably stored in the blockchain (or at least the hashes of elaborated reports).
Additional service providers are part of the network.
Depending on the privacy of the production consortium, regulators and auditors may have direct access to the blockchain application.
The token is required to pay for the transaction of the smart contract execution. It can be considered as something similar to Ethereum’s GAS cost. A part of the transaction fee is then frozen for an extended period.
The token has further utility functions which are related to the role of the users, like a loyalty fee for manufacturers, an access fee for premium membership functions, or as rewards for specific network activities.
You can either join the marketplace as a seeker of manufacturing capacity or as a manufacturer, or you may want to join with a group of your suppliers. We set up your version of an ARXUM Protocol in a smart contract. This includes information like your general terms, payment terms, etc. Further, we have to connect your production facilities, either with the ARXUM Connection Box, or at the level of your Manufacturing Execution Software, to the ARXUM Production Network. The box pulls information from the blockchain and extracts necessary production data. The box submits this to the machine.
If you have a SAP-system, we could provide an interface for information exchange.
If you have a MES-system, the production order needs to be pushed into your complex production environment. What our software does then, is to provide the data to the MES-system. The MES also exchanges data with the ERP. For the MES-system, we provide a source of orders. The adaptation process for you as a company is very small. We offer an interface so that your manufacturing execution software can collect more orders.
Single machines can be integrated through the ARXUM Connection Box (ACB). The ARXUM Connection Box provides a wide range of machine connectivity which can be utilised to integrate a large variation of different production machines. The range of I/O functionality leaves plenty of room to integrate different machines and to establish the connection in a way, which ensures, that without specific physical knowledge of the production machine there is no traceless removal possible.
Through an integrated configuration interface, the different input channels can be linked together with pre-defined logic production states, which will lead to transaction events.
There are the following main ways to use the ACB with single machines:
- ARXUM works with interested OEMs of production machines, to integrate the ACB on their own accords. Linking the machine control system to the ACB’s embedded DApp natively, provides a secure network connectivity, blockchain connectivity and immediate access to the worldwide Production Protocol.
- For machines with a standard data interface (such as 3D printers,) a driver functionality will be provided by ARXUM. Over time, this will gradually extend to other machine types, such as CNC milling and drilling machines. This features allows single individuals to connect their machines directly to the ARXUM production network, offering their standardised production capabilities on a manufacturing marketplace.
- Any other machine may be connected by using single input channels linked to basic contractual events
Production lines with multiple production machines and larger facilities are also connected through the ARXUM Connection Box. But instead of connecting single machines to one ACB, the ACB acts as a security anchor and hardware wallet, interconnecting the complete production facility to the different ARXUM ledgers.
The ACB contains the private keys to sign all blockchain transactions.
For this purpose, the different LAN interfaces of the ACB will be used. LAN1 will connect to the Production Protocol via an internet connection. LAN2 will connect to the manufacturer’s intranet and interact with company IT systems.
ARXUM provides standard interfaces to major order processing systems. These are located on two levels:
- ERP level (enterprise resource planning)
- MES level (manufacturing execution system/production planning system)
The most important level is the manufacturing execution system or production planning system, as these care for the job order for all manufacturing tasks, take care of prioritising special jobs, circumvent unavailable production machines and care for BOM and supply of materials.
Currently, a MES usually collects active production orders from the ERP system and the production manager arranges for their execution. ARXUM simply provides a further channel to collect production orders. Either this production order comes with all related information necessary (bill of material, recipe, numbers and amounts, machine settings, etc.) or this data is sought from the leading ERP system.
The ERP system is the least important for ARXUM. As through ARXUM’s Production Protocol also the material suppliers will automatically get their production order in pre-timed manner, there is actually no need for the ERP system to track material stock for production. This is only necessary in order to keep a correct in-house inventory count. As as a smart contract in the ARXUM production protocol also cares for payment and settlement, the ERP system only needs to match the already settled payment transaction ID to the correct internal cost centre.
Through the fully flexed functionality of the ARXUM worldwide Production Protocol, an ERP system can be completely circumvented.
Yes, ARXUM can even integrate manual manufacturing capabilities without machinery! This can be highly relevant for, but not limited to:
- sewing shops
- charitable or non-profit workshops
- manual assembly companies
- wrapping and packaging
- compiling/assorting/assembling product kits
- and many more
The Arxum Connection Box (ACB) is an edge computing industrial IoT device, which contains a secure webserver. A manual workshop owner can use the ACB web interface to the embedded DApp of the ACB to manage production orders.
In this case the complete interaction is manually operated:
- accepting orders
- reporting manufacturing progress
- reporting production completeness
- providing proof of existence
- documenting proof of ownership
From a security perspective, there is a breach here in the automated chain of the production execution and blockchain interaction. However, the breach is not worse than in any other application linking human interaction and physical assets to blockchain applications.
Proof of existence can be provided by means of photos. The validity of these claims are easily verifiable at delivery time.
Proof of ownership can be provided by entering serial numbers of products in a web mask or by marking customised products with a transaction ID provided by ARXUM.
The ACB is equipped with an integrated proof-of-presence mechanism. As the ACB is naturally connected to the internet, it is accessible from the network. For remote access to the device, the user must prove that he/she has physical access to the device. This is implemented by a random number generator, which generates a new random 4 digit number for each login attempt. This number has to be entered at the front of the device with the integrated LCD and impulse button.
Prior to delivery, the ARXUM Connection Box is initialised by ARXUM. The aforementioned TPM module is taken into service and the secret key infrastructure is generated on the device. An exchange of keys is performed and the shared secrets are safely stored on an offline computer at ARXUM and the ACB itself. This enables a secure channel instantiation with synchronous encryption and avoids a Diffie-Hellman key negotiation.
With an increased sales level of ARXUM Connection Boxes, this initialisation step will be delegated to trusted partners, providing the necessary infrastructure.
Based on a locked EMMC ROM memory, a secure boot process is implemented, creating a chain of trust when the system is started. The mechanism reads the first part of the operating system from a locked read-only area from memory, assuring that the boot process cannot be forked.
Operating System Signature
The Linux operating system is signed with a private key hidden in the TPM module. Based on the secure boot process, each subsequent operating system component is only loaded when it bears a signature - in fact a hash value - which corresponds to the hash value which has been stored in the TPM for the respective operating system module.
This mechanism is continued into the file system and the start of the user applications.
Based on the direct attestation and key exchange prior to delivery of the ACB, ARXUM provides operating system updates and application updates, which can be transmitted through an a-priori secured channel to the ACB. Based on the securely stored keys, ARXUM signs the update files prior to transmission to the ACB. The ACB can safely verify the provenance and correctness of the provided updates prior to installation in the system. This assures that system updates, patches and upgrades are only provided by ARXUM.
On different places on the electronic circuit boards of the ACB, there are sensors which can detect whether the body housing has been opened. The device controllers are battery buffered and can detect this security-relevant event up to a certain time without power supply. The security breach is documented in the system logs and can trigger different actions.
All security related actions performed on an instance of an ACB are recorded in a specific distributed ledger, the "ACB Ledger.“
Each ARXUM Connection Box is taken into service through ARXUM. During initialisation, the unique ID of each TPM is extracted and compiled into a unique ACB ID. Furthermore, a set of private and public keys is generated and exchanged with the ACB and partly stored on an offline (cold) ARXUM server. The initialisation creates a new transaction in the ACB Ledger and provides a proof-of-existence of each ARXUM Connection Box.
- Updates and Patches
Each update and patch, provided through a secure channel by ARXUM and successfully installed on an ACB, will be documented as a transaction on the ACB ledger. The ACB ledger lets you verify the software versions of all existing ACBs. This can be used to identify (and potentially sanction) those devices which do not provide the necessary security patches for a secure blockchain interaction.
- Malware Infections
Although highly improbable, should the ACB boot process detect a malware infection during system start or operation, the case of infection for the specific device is stored in the ACB Ledger.
- Hardware Breaches
Based on the detection mechanisms to sense an opening or fracture of the device body, such events will immediately be stored in the ACB Ledger as soon as the network connection is available.
These security mechanisms implemented on a public ledger provide a further layer of trust when executing the ARXUM Production Protocol directly on the ARXUM Connection Box.