Resource Manager The Resource Manager is implemented as a custom STAF service called RESMGR. RESMGR manage resources at the execution engines level (TEEs and BEEs). RESMGR does not manage individual HW resources such as DUTs, DVDs, etc. TEEs and BEEs are responsible to register/unregister with the RESMGR TestLink’s hw_asset field identifies required TEE capabilities

DISPATCHER TMC’s StafProc RESMGR TMS/User Request TEE TEE Register w/ RESMGR and provides its type and capabilities upon startup 2.Test Request send to TMC 3.DISPATCHER query RESMGR for available TEE type w/ required HW_ASSETS (capabilities) 4.RESMGR provides TEE machine name 1.DISPATCHER send test request to TEE machine gotten on step 4. 2.TEE completes job execution and notifies DIPATCHER. 3.DISPATCHER releases TEE 4.TEE unregister w/ RESMGR upon shutdown 7 8 Test Flow

Resource Manager TEE 1 Registration TEE 2 Registration TEE n Registration STAF.cfg file Hardware Request from Test Case Definition The Resource Manager selects a TEE that contains the requested hardware.

TestLink’s hw_assets field The hw_assets field identifies the equipment needed to run a test case. The hw_assets field is made of one or more equipment reference lines. An equipment reference line has the following format: –ref=[hw_asset_type, capabilities] ref: Reference. This is the name that the test execution logic will use to refer to this equipment hw_asset_type: Identifies the equipment type (see next slide) capabilities: Identifies the equipment capabilities (see next slides)

hw_asset_type The hw_asset_type is just a label to identify a piece of equipment. From the Test Automation Framework point of view any value is acceptable, however it is important to agree on using the same labels to identify the same equipment, so it is possible to share test plans. HW Assets types currently in used: DUTs: dm355, dm365, dm644x, dm6467, dm6467t, gghd-evm, omap3530, omapl137, omapl138, beagle, beaglexm, am1707, am1808, am3517, am3730 Test Equipment: dvd, camera, tv, audioplayer, mts4e, videoclarity, pqa500, pesq, qmaster, spectralab, linux_server

capabilities The capabilities is just a string that identifies capabilities of a piece of equipment. From the Test Automation Framework point of view any value is acceptable, however it is important to agree on using the same labels to identify the same capabilities, so it is possible to share test plans. Identifying the capabilities is required because not all the boards of the same type have the same capabilities (i.e. different nand chips, different usb configs, slave vs host, etc.). The capabilities value is just a string with zero or more capabilities separated by underscore ‘_’. The capabilities are one or more lowercase letters or numbers. Example of some capabilities: videocapturentsc, videocapturepal, videocapture720p, videocapture1080i usbhostmsc, usbhostaudio, usbhostvideo nand4k, nand2k, sd, sdhc, mmc.

TEE Registration When a TEE is powered up, its Stafproc process should register w/ the Resource Manager. The Resource Manager information is obtained from its Staf configuration file The registration message should contain the TEE type and its capabilities The TEE capabilities are made of one or more equipment expressions separated by semicolon An equipment expression identifies the hw type and its capabilities –[“hw_asset_type”, capabilities]. For example –[“dm355”,usbslave_videocapture];[“dm365”,usbhostmsc_usbhostaudio]; [“dvd”,ntsc];[“dvd”,pal] When a TEE is powered down, its Stafproc process should unregister w/ the Resource Manager.

RESMGR Messages ADD TYPE NAME CAPABILITIES DELETE TYPE NAME CONFIRM LIST QUERY TYPE NAME REQUEST TYPE TIMEOUT [s|m|h|d|w] [CAPABILITIES ] RELEASE TYPE NAME VERSION HELP

ResMgr Algorithm Details Find set of Execution engines w/ appropriate HW types and capabilities Filter out Execution engines who doesn’t seem to be alive (ping request) Select engine w/ fewer number of pending request If two or more engines have the same number of pending request, select the one w/ fewer hardware capabilities