Build the test.
Run production.
Understand every result.

BHARAT TEST SUITE brings equipment, product rules, test logic and production records into one Windows application. Configure the station, then build and maintain the process around your product.

Why it matters Manage product variants and station changes through configuration, with reusable test logic and a consistent operator process.

Connect supported instruments from different manufacturers and give each one a meaningful device name. Test steps use that configured device, while each product model keeps its own identification rules.

• Serial / RS485
• LAN / TCP
• SCPI
• Modbus
• USB / GPIB / VISA
• CAN / CAN FD
• LIN
• DAQ / I/O
• Camera / printer

Compatibility depends on the exact instrument, protocol and installed drivers. Simulation is a development aid; production validation uses the intended hardware.

Set the order of operations, choose a device action, interpret its response and compare the result with your limits. Group related checks so the flow stays understandable as it grows.

Configure detailed operations in dedicated workspaces, then link them into the main sequence. Measurement, communication, programming and inspection can contribute to the same test process.

Availability depends on licence, permissions and supported hardware. ST-LINK, SEGGER Flasher and XDM4011 programming workspaces are Beta; confirm the provider, tool and target combination.

The operator selects a plan and identifies the units. The plan connects each DUT position with its model, sequence and fixture assignment, with progress and results shown during execution.

Illustrative two-position arrangements. Parallel execution depends on hardware, shared resources and reviewed configuration; it does not imply a fixed throughput increase.

1. Admit the correct unit Apply barcode and interlocking rules, device readiness, golden-sample requirements and configured start conditions.
2. Follow the live test Show current steps, group progress, measurements and per-DUT results. Apply the configured retry and continuation policies.
3. Complete the process Run result actions, NG-bin handling, label printing and scan verification where enabled. Resolve configured delivery holds before the next unit.

Why it matters Product identification and completion checks become part of the operator workflow, alongside the measurements.

Exchange records with production systems, give supervisors visibility and send quality notifications. Each function has a distinct purpose.

Data Link requires its own entitlement. Smart Factory Monitoring provides reporting, not remote control of test outputs. Confirm the required licence modules and factory interface contract.

Start with the production picture, narrow down a failing check or model, then inspect the individual unit. These are real application views populated with fictional demonstration records.

Failure Analysis Model Analysis Barcode Search Dashboard

Which checks need attention?

Compare step failure counts, rates and limits. In this fictional lamp dataset, output voltage accounts for 28 of the 60 failed attempts.

Failure Analysis Actual software screen

Enlarge

How do different models compare?

Compare totals, pass rates and cycle times across DEMO-LAMP, DEMO-MOTOR, DEMO-SENSOR and DEMO-CONTROL before investigating the individual records.

Model Analysis Actual software screen

Enlarge

What happened to this unit?

Follow a barcode across its saved attempts. This example has an NG attempt followed by an OK retest, with measured values and limits available for review.

Barcode Search Actual software screen

Enlarge

What is the production picture?

Read totals, pass rate, failures, cycle time and handling time together. The dashboard shown here filters the demonstration records to DEMO-LAMP.

Dashboard Actual software screen

Enlarge

Demonstration dataset: 4 models and 4,200 attempts. Dashboard and Failure Analysis show DEMO-LAMP’s 1,500 attempts. These records are not customer production or a product-performance claim.

1. Trace the unit Find its model, barcode, attempts, measurements and available attachments. A retest remains part of the recorded history.
2. Review the pattern Filter reports by model, period, result or barcode. Compare failures and timing before deciding which process to investigate.
3. Use the evidence Export records for review. Configure labels, serial generation and scan verification to connect identification with the production process.

The Activity Log connects recorded user actions with their session and time. For saved configuration changes, inspect the affected fields and their previous and updated values.

Activity Log Actual software screen

Enlarge

Access and export depend on the user’s permissions. Requested actions and confirmed saved changes are distinct records; field values appear where recorded.

Investigate communication and fixture behaviour before changing the test. Use diagnostic evidence to isolate the cause, then evaluate timing changes through a controlled trial.

Communication Studio Inside the software

Enlarge

1. Communication Studio Preview requests and inspect TX/RX traffic. Use response trials and Byte Lab to understand received values.
2. Maintenance & service Inspect live inputs and permitted manual outputs. Review fixture counters, due conditions, service records and diagnostic logs.
3. Virtual development Exercise configured logic with simulated responses, then verify communication and behaviour with the intended hardware.

Keep the electrical design, access rules, recovery tools and operating guidance alongside the test workflow.