[Automated-testing] Farming together - areas of collobration

Bird, Timothy Tim.Bird at sony.com
Thu Nov 16 14:42:34 PST 2017



> -----Original Message-----
> From: Andrew MURRAY on Wednesday, November 15, 2017 2:55 PM
> > -----Original Message-----
> > From: Bird, Timothy [mailto:Tim.Bird at sony.com]
> > > I find that when managing a farm, it would be nice to add new boards
> > > without having to change some integral farm configuration or have
> > > particular access rights to 'the farm' to plumb in a new board. I.e.
> > > so that anyone can add a farm without risk of breaking anything else.
> > > In our farm we install boards on rack-mount shelves - I think it would
> > > be a fantastic idea if we could define a standard that:
> > >
> > > - Standardises connectivity between a shelf and the farm PC (perhaps
> > > just USB, Ethernet and power)
> > > - Requires each shelf to contain a USB stick with a file that
> > > describes the board, the physical USB topology between the shelf and
> > > its components (USB serial adaptors etc)
> >
> > When you say "shelf", I think "DUT controller".  I would like standardized
> > connectivity between a DUT controller, and the using software (be it
> command
> > line, test framework, etc.).  For me, I'd like to see a standard interface so
> that
> > these controllers can be discovered and utilized with minimal effort.
> 
> I think we're referring to two slightly different things (which is why a glossary
> would be useful)...

We are (talking about different things), but it would be nice to address these
with similar mechanisms.
I think your shelf idea has merit.  In a different, but related use case, I see a
few examples of people doing all (or most) of the control operations to support
board automation from a single (usually custom) board.

I refer to hardware used to control the Device Under Test as "DUT control" hardware.
(or as a "DUT controller").  It would be nice if there were standards for discovering
the capabilities of such controllers (what features do they have?  What ports can
they control?)  It would be nice to be able to use a similar mechanism (a file
on USB mass storage device) to identify these and to discover their capabilities,
if they do not support inspection naturally.  There might or might not be a one-to-one
correspondence between DUT controllers and DUTs.

A pdu (power distribution unit) is one form of a DUT controller, but there are lots
of other types.

The descriptor for these is not the same thing as a shelf descriptor, but it might
shares some commonalities.

> 
> I'm not sure what your farm environment looks like, but in ours we have one
> 'farm PC' that everything is plugged into. I've seen other farms where each
> board has a BeagleBone or similar connected to it, and then another 'farm PC'
> that connects to the BeagleBones. I.e. we may all have different physical
> architectures.
> 
> To further explain our use-case. Imagine a farm PC and a rackmount with a
> load of empty shelves. We can then connect a USB hub to the PC and
> connect a bunch of USB A to B cables to it. The B end of the cables can be
> fixed to the empty shelf. We can then connect a rackmount power switch
> (PDU) and likewise connect a power cable to each empty shelf. At this point
> we have a concept of shelves with a standard set of connectors (a B USB
> connector and power supply). My vision was to standardize these connectors
> (maybe some day someone can create a nice connector!). Then when you
> put a board on the shelf it connects to the USB hub (for serial, perhaps USB
> relay etc) and power and includes some USB text file that describes the
> topology between the standard shelf connector and the board. Thus the
> shelf self describes the board to the farm. It would then be the farm's grass
> layer that abstracts all this to a standard API.... though this is just my starting
> view.
> 
> >
> > I think a survey of DUT controllers would be good as well.
> > I will offer to do one, if no one else is interested, and to put the results on
> the
> > elinux wiki.
> 
> The definition of DUT controller may need to be clearer, but sounds like a
> great idea.

I'll start collecting data on DUT controllers, on the wiki.  My particular
focus will be on multi-function devices.

...

I'll also start a glossary.
 -- Tim



More information about the automated-testing mailing list