Deployment Options

The Agent can be deployed in a variety of system architectures, distributed across Agent, Device Under Test, Automated Test Equipment, and the Cloud Service.

Parts of a Testbed

Agent

knilb is an example implementation of an Agent. The proxy client that controls the interaction between the Cloud Service, the Device Under Test, and the Automated Test Equipment.

ATE (Automated Test Equipment)

Equipment senses the physical I/O of the Device Under Test. RaspberryPi and Arduino are capable devices to use as Automated Test Equipment. The Automated Test Equipment must provide a web app with RESTful API to access data, e.g. Raspberry Pi GPIO pins using a break-out board like Pi-EzConnect.

DUT (Device Under Test)

Your connected device. The Device Under Test must be accessible via a RESTful API to access and control the device.

Co-located Agent

Deploying the Agent on the Automated Test Equipment, such as a RaspberryPi, allows for autonomous automated testing. The user can SSH to the RaspberryPi to run the Agent or even add a simple phyiscal trigger button:

DUT--LAN-->Agent with ATE(RaspberryPi)--Internet-->Cloud

Distributed Agent

Deploying the Agent separately from the Automated Test Equipment provides more flexibility to control the Agent through rich interfaces like Command Line Interface. In this deployment architecture, the Agent could be deployed on another embedded device instead of a laptop, too:

DUT---------------LAN-->
                       >Agent(Laptop)--Internet-->Cloud
ATE(RaspberryPi)--LAN-->