Our living lab is the embodiment and realisation of an agent-based Additive Manufacturing (AM) system the enables our 3D printing machines and the jobs being submitted to talk to one another and negotiate who is going to manufacture what.
The living lab enables us to:
- demonstrate the real-world applicability and realisation of agent-based manufacturing systems;
- investigate the practical and technical challenges of implementing systems in the real-world; and,
- validate our numerical models that simulate the potential of agent-based manufacturing systems to meet our needs.
One of the aspects that we’re investigating is the security of agent-based AM systems. In this post we describe the security features of our architecture. But first, we need to describe the architecture itself.
The architecture.
The system architecture that enables machines to communicate with one another and the jobs being submitted is entirely web-based using well-established cutting edge software packages. We use a webapp that connects to our machines either through their in-built Application Programming Interfaces (APIs) or directly through USB using the WebSerial protocol. This enables the webapp to evaluate the machine’s status, submit jobs to a machine and cancel jobs on the machine. The webapp then acts on behalf of the printer in our agent-based manufacturing system. For all intents and purposes, the webapp is the agent for the machine and is where a user can specify the logic by which a machine wishes to communicate and make decisions upon which jobs to select. For example, a machine may be set-up to identify and select the job that was submitted first or the job with the longest print time. The webapp then brokers a connection to our server – the broker – using socket.io. The webapp can then send messages on behalf of the printer, which the broker then passes onto the relevant agents.
A webapp is also used for the submission of jobs to the system. Users upload their gcode that they wish to manufacture and add some details about the job. The webapp then becomes the agent that acts on behalf of that job and is where the user can set the job logic. For example, I want to be printed as soon as possible or I want a specific type of machine. The webapp then brokers a connection with our brokering server and the communications can begin between our machines and jobs. It’s really that simple!
Another neat advantage is that a single computer/device can represent multiple machines and jobs by simply opening another tab in the browser! But let’s stay focused on the security element of the architecture.
Making it secure.
There are a number of things we do / can do to make our architecture secure, these are:
- Communication is through HTTPS. If you ever thought what that lock icon in the corner of your browser window is, then that’s telling you you’re using an encrypted channel to pass information between machines.
- Our service uses a cloud-based server but the service could be set-up on a Local Area Network (LAN) that could be disconnected from the internet.
- The service can also be set-up to run through a Virtual Private Network (VPN).
- Machine and job agents must authenticate their connection with the broker. This is achieved through a unique API key. Other authentication methods could be used and we’re looking at techniques such as JSON web token and OAuth.
- The broker server only holds ids (i.e., phone numbers in a phone book) to enable it to broker connections and pass messages between machine and job agents. No design data or information regarding the machines and jobs is required to be stored in the cloud. We do have logging functionality and we use this to study the behaviour of the network. This can be turned off and/or reduced based on the needs of the stakeholders setting up the network.
- The broker server HD is encrypted.
- The broker’s code has been made open-sourced enabling us to gain the experience of the community to maintain and evaluate the security of the code.
- The broker server can support multiple networks with neither interfacing with one another (think subnets in networking).
- We’re keeping to a minimal number software dependencies using proven and well-established packages, such as socket.io, react, typescript, jest and ant.design.
- Typescript is being used throughout the software stack to support coding practice and ensure errors are caught and the expected output from each piece of code is described and documented.
- Unit testing is present in all our code bases and we’re continually updating and implementing more tests to catch all manner of event.
- Continuous Integration/Continuous Deployment (CI/CD) software practices are being implemented to ensure upgrades to the system are full-tested and sandboxed prior to deployment in the production environment. A particular advantage of having the entire stack web-based is that deployment of new code is fast and simply requires end-users to refresh their pages. You may have seen this in popular applications such as Web WhatsApp.
And then there’s the inherent security of the architecture itself. For example,
- Ad-hoc communication. If someone was able to circumvent the encryption and authorisation required then they would then have to wait, and hope, to be listening at the right time between the right communication channels.
- Machine and job agents can connect and disconnect as they please and new ids assigned in the address book on the server. This could obfuscate the history of which machines talked to which jobs.
- Agents need only to send the minimal data required for machines and jobs to reason and formulate an answer to the questions being posed (e.g., are you available? Are you capable of printing this job?). Agents can provide additional information if they so which may enable richer reasoning, but this is it the discretion of the agent and the end-user who has configured it.
So, with these features, we are confident that we can make an agent-base manufacturing system that is secure for many different contexts from university/school workshops through to highly regulated and IP/operationally sensitive industries.
There will always be the case of trusting the parties utilising the platform and we appreciate we are not security experts. Our interests are in how these manufacturing systems support communities in producing the items they need. If you research or interests in the security of these platforms, then do get in touch. We would love to hear from you.
But if there is one take away from this post then I would say that the technologies do exist in providing the level of security required for your operations.
Our living lab of agent-based printers are currently support the manufacture of components for research and we’re hoping to soon open it up to support student projects across the University. So, if you’re interested and want to find out more then please contact us. We’re happy to provide demonstrations both physically and virtually as well as support anyone who wishes to deploy their own agent-based manufacturing system.