Mechanism Developers Guide#
Introduction#
Fuze™ Test supports pluggable control and acquisition “mechanisms”—Python classes that interact with hardware (e.g. flash programmers, relays, GPIO, CAN).
These mechanisms implement a shared interface and can be referenced in test case JSON as command types.
This guide describes how to build and integrate new mechanisms.
Core Interface#
All mechanism classes must inherit from:
class TestCommandRunnerIF(object):
def __init__(self):
pass
def run(self, command_dict):
raise NotImplementedError("Mechanism must implement `run()`")
Your mechanism must implement run(command_dict) to perform the actual work.
Available implementations include:
TcsCommandRunner — for structured command sequences
CfeCommandRunner — for CFE-based communication
CssCommandRunner — for device state control
Creating a New Mechanism#
Subclass TestCommandRunnerIF:
class MyCustomRunner(TestCommandRunnerIF):
def run(self, command_dict):
port = command_dict["port"]
signal = command_dict["signal"]
self.toggle_gpio(port, signal)
Define your logic in run().
Optionally add init parameters (e.g. serial port, config).
Place your file under:
producttest/pta_functions/
Referencing from Test JSON#
Each test case defines commands like this:
{
"TYPE": "MYRUNNER",
"CMD": {
"port": 17,
"signal": 1
}
}
The TYPE string must match what the PTA factory uses to map to your runner class.
Factory Registration#
You may need to modify the command dispatcher in ProductTestAdapter to add a mapping:
if cmd["TYPE"] == "MYRUNNER":
runner = MyCustomRunner()
runner.run(cmd["CMD"])
Make sure to log errors, validate inputs, and return success/failure markers.
Testing and Debugging#
Use the FUZE_DEBUG=1 env var to enable verbose logs.
Write unit tests that call your runner directly.
Reuse ptalogging.logger for consistent logging format.
Confirm your mechanism integrates by executing a minimal test case.