Testing & HIL

Testing & HIL

Automated tests in Python against live signals — traced to requirements and reported straight into your CI pipeline.

MACS tests are plain Python classes that talk to the running system. Each test reads and writes real signals — from simulated models, real hardware, or a mix of both — and checks the system's response step by step.

What a test looks like

class ChargeResponseTest(MACSTestCase):
    def setup(self):
        with self.step("Initialize"):
            self.set_signal(vcan0.ControlSignal, 0)
            self.stabilize(1.0, "Wait for system to settle")

    def execute(self):
        with self.step("Apply test condition"):
            self.set_signal(vcan0.ControlSignal, 1)

        with self.step("Verify response"):
            self.verify_signal_above(vcan0.ResponseSignal, 500, timeout=5.0)
            self.verify_signal_in_range(vcan0.ResponseSignal, 450, 550)

Every step is logged, so a failure tells you exactly which condition wasn't met, and when.

Run and report

The Test Manager runs selected tests, the whole suite, or only the tests that failed last time, with live pass/fail status and timing. Results are stored per project and can be exported as HTML reports for people, or JUnit XML for your CI system.

Requirements traceability

The Requirements Manager organizes requirements by subsystem, with type (functional, safety, performance, usability, compliance, interface), priority, and status from draft to verified. Link each requirement to the tests that verify it, and MACS calculates coverage from the latest results. Requirements can reference signals directly, be imported from CSV, and be exported to PDF for reviews.

Challenges we solve

What you're working around today, and how Testing & HIL addresses it.

Manual bench testing doesn't scale

Tests are Python code — re-run them at any time, with every result stored in the project's test history.

Tests break when signal names change

MACS generates signal constants for your project, so tests reference signals by name with editor autocompletion.

Running the same test under different conditions

Parameterized tests merge suite defaults, per-test values, and one-off overrides for each run.

Proving that requirements are actually verified

Link tests to requirements. Coverage is calculated from the latest test results, and reports export to PDF for reviews.

Test results stay on the bench

JUnit output feeds your CI pipeline, and tests can also be started and followed from the web dashboard.

Intermittent faults that are hard to reproduce

Record CAN traffic and signals while testing, then replay the CAN traffic to reproduce the conditions.

Testing before the hardware is ready

Run against virtual CAN interfaces and simulated models, then switch individual signals to real hardware as it arrives.

Inside the platform

Requirements Manager

Requirements Manager

Requirements organized by subsystem, with linked tests and coverage status.

You might also like

SparkBit

SparkBit

Compact Linux industrial computer for embedded control and multi-bus sensor bridging.

SparkFrame

SparkFrame

Customize your own enterprise rack.

SparkByte

SparkByte

The big brother of the SparkBit. More power, more CAN channels, more everything.

Interested in Testing & HIL?

Get in touch for a demo or quote.