DEV Community: Marco

PIC64-HPSC: what early radiation results mean for RISC-V firmware in space

Marco — Fri, 30 Oct 2026 08:25:17 +0000

Microchip's PIC64-HPSC has reached another milestone in the development of next-generation spaceflight computing. In its update of October 27, 2026, the company reports early radiation-characterization results for the PIC64-HPSC1000-RH variant and progress in customer evaluations. For embedded-system developers, the interest lies in combining multicore RISC-V processing, fault management and onboard communications.

The family was introduced on July 9, 2024. The latest announcement concerns the platform's maturation. Understanding it requires separating architectural capabilities, experimental findings and the requirements of a particular mission.

The technical points behind the announcement

Computing: eight 64-bit SiFive X280 application cores, alongside dedicated system and security controllers.
Radiation: early TID characterization to 200 krad(Si) and SEL testing to 78.2 MeV·cm²/mg on the PIC64-HPSC1000-RH, under the conditions specified by Microchip.
Development: customers in the Early Access Program are evaluating silicon and development kits; integration into a flight system still requires mission-specific verification.

What the announced results establish

Microchip's October 27 announcement also describes system-controller operation during SEE characterization completed to date, without uncorrected errors or a need for external resets. That finding has a defined scope: the particular controller and the reported test campaign. It does not establish the absence of errors across every subsystem, workload or radiation environment.

The engineering significance is the transition from a proposed design to measured behavior on silicon. Assessing a mission, however, requires the complete reports: samples and lots, supply voltages, temperatures, bias conditions, workloads, dosimetry and acceptance criteria.

Inside the architecture: eight application cores, ten cores overall

Despite the PIC name, PIC64-HPSC is a 64-bit RISC-V MPU. Its application complex contains eight SiFive Intelligence X280 cores with vector extensions; an additional core manages the system, while a separate controller handles security. This explains why the product page lists ten cores overall while application-processing specifications refer to eight.

The DS00005391D technical brochure specifies frequencies up to 1 GHz and different core and cache configurations. Functional separation matters: image processing, system supervision and key protection have different requirements even when they share a device.

PIC64-HPSC: 64-bit multicore RISC-V processing for onboard systems. Conceptual illustration.

Vector processing: how to interpret the performance figures

At the family's introduction, Microchip specified up to 2 TOPS at int8 or 1 TFLOPS at bfloat16 for vector matrix-multiplication operations across all eight cores. Those figures refer to particular operations and numerical precisions. They do not describe the execution speed of every algorithm or the performance of a complete onboard application.

An engineering assessment must account for transfers, memory access, synchronization, the operating system and power consumption. A classifier may benefit from vector operations; a pipeline dominated by acquisition and I/O may remain bandwidth-limited. Selecting a configuration requires measuring latency, energy and correctness on the actual workload, including fault conditions.

The science: what radiation does to space electronics

NASA's Radiation Hardness Assurance material describes environments that include particles trapped in planetary magnetic fields, solar-particle events and galactic cosmic rays. Orbit, inclination, duration and shielding change the exposure: two satellites described simply as operating in LEO can face substantially different radiation profiles.

At least three phenomena must be distinguished: total ionizing dose, displacement damage and single-event effects. Good behavior against one does not establish immunity to the others. As ESA's discussion of radiation-resistant circuits explains, semiconductor-process properties and design techniques affect a circuit's response. The RISC-V ISA defines executable instructions; the ISA alone does not make a chip radiation-resistant.

TID: 200 krad(Si) is an absorbed dose in silicon

Total Ionizing Dose describes absorbed ionizing energy per unit mass. In MOS devices, trapped charge in oxides and interface states can alter threshold voltages, leakage currents and electrical margins. The response also depends on technology, dose rate, temperature, bias and annealing.

The physical definition and unit conversion are:

D = absorbed energy / mass
1 rad = 0.01 Gy = 0.01 J/kg
200 krad(Si) = 2,000 Gy(Si) = 2 kGy(Si)

(Si) identifies the reference material. These quantities describe absorption in silicon and must not be confused with a biological equivalent dose in sieverts. NASA GSFC material on radiation hardness provides context for the terminology and characterization process.

The family documentation distinguishes a 100 krad(Si) specification with testing to 200 krad for the RH variant. The 2026 announcement reports an early characterization result at 200 krad(Si). Treating that figure automatically as a newly guaranteed operating dose would erase the distinction between an experimental result and a device specification.

TID and SEL describe different phenomena: accumulated ionizing dose and response to a single-particle effect.

SEE and SEL: why LET is not total dose

A single particle may generate enough charge to disturb a circuit node. A single-event upset (SEU) can change a bit; a single-event transient (SET) produces a transient disturbance; a single-event latch-up (SEL) can trigger a sustained parasitic high-current path. The outcome depends on the device and its protections: latch-up may require power interruption and can become destructive if the current is not controlled.

Linear Energy Transfer, in the density-normalized form commonly used in component testing, describes energy deposition along a particle's track:

LET = −(1 / ρ) · dE/dx
unit: MeV·cm²/mg

Consequently, 78.2 MeV·cm²/mg is neither accumulated dose nor the total energy of an arbitrary ion. Microchip's SEL result applies within its stated experimental conditions. Comparing devices also requires ion species and energy, penetration, angle of incidence, temperature, voltage and fluence. The ECSS material available through SPENVIS distinguishes these effects and introduces cross-section as a measure of susceptibility.

From a test result to mission risk: cross-section and statistics

The cross-section σ expresses susceptibility to an effect, typically in cm² per device or per bit. For heavy ions, it is often characterized as a function of LET. A simplified event-rate model combines this response with the expected differential flux behind shielding:

R ≈ ∫ σ(L) · φ(L) dL
Expected event count ≈ R · duration

Here, L denotes LET and φ(L) is the differential flux consistent with the chosen model. This explains the method; it is not a calculation for PIC64-HPSC. The complete response curves and mission profile are unavailable in the announcement. Protons and other mechanisms may require energy-based models and separate contributions.

Even “zero observed events” needs a statistical interpretation. Under an ideal-detection Poisson counting model, with zero events observed during fluence F, the one-sided 95% upper bound is:

P(0 events) = exp(−μ)
μ95 = −ln(0.05) ≈ 3
σ95 ≈ 3 / F

The derivation shows why observing no events places an upper bound on susceptibility rather than proving it is zero. Without fluence, monitoring coverage and test configuration, the announcement does not support a reliable numerical event-rate estimate.

RH, RT and Engineering Model: choosing the appropriate variant

The official family page distinguishes radiation-hardened and radiation-tolerant devices for different applications. The table summarizes family-level information; the October 27 result concerns the RH variant specifically.

Family documentation: check the exact part number and documentation revision applicable to the design.

Variant	Indicative applications	Reported radiation information
PIC64-HPSC1000-RH	MEO, GEO, deep space	TID 100 krad(Si), testing to 200 krad; SEL approximately 78 MeV·cm²/mg in family documentation.
PIC64-HPSC1100-RT	LEO and New Space applications	TID 50 krad(Si); SEL 42 MeV·cm²/mg.
Engineering Model	Development and laboratory work	The product table does not assign flight-applicable TID or SEL values.

A similar software environment makes development easier, but does not make laboratory models and mission devices interchangeable. Guaranteed conditions, qualification status and the documentation for the precise orderable part must be checked.

System reliability: lockstep, ECC and isolation

Microchip's technical white paper describes multiple protection layers: configurable Dual-Core Lockstep pairs, WorldGuard hardware partitioning, ECC protection and memory-interface error correction with scrubbing functions.

In lockstep, paired cores execute together and a mismatch can reveal a fault. That supports detection, but does not automatically identify the correct result or replace a recovery strategy. Cores allocated to redundancy are not simultaneously independent throughput resources for the application.

ECC corrects the error classes supported by its code and memory configuration. Scrubbing periodically checks and rewrites corrected data to limit error accumulation. Hardware isolation constrains access between domains; meeting deadlines additionally requires analysis of scheduling, arbitration and contention for shared resources.

These capabilities belong within a Fault Detection, Isolation and Recovery architecture. NASA's NESC recommendations on SEE emphasize considering both unrecoverable effects and recoverable errors, including recovery time. A system that restarts must also restore a coherent operational state.

Onboard networks and autonomy: data must reach the cores

The design combines Ethernet TSN, SpaceWire, PCIe Gen 3 and CXL 2.0 support. The cited 240 Gbit/s Ethernet-switch figure describes aggregate internal switching capacity, rather than the rate of an individual port. RoCEv2 supports low-latency transfers with less CPU involvement. These interfaces connect computing resources to sensors and potential accelerators.

An illustrative design scenario is an Earth-observation pipeline: acquisition, calibration, selection of useful regions, compression and downlink preparation. Local processing can reduce the volume sent to Earth. Actual benefits depend on the algorithm, required scientific quality and available energy; fewer transmitted bytes alone do not guarantee a better mission result.

Satellite platform with articulated solar arrays, a high-gain antenna and optical and thermal subsystems. Conceptual application scenario. Earth: NASA/Goddard Space Flight Center Scientific Visualization Studio.

Implications for firmware and mission-software developers

The evaluation platform and BSP allow development to begin before the final board exists. The Evaluation Platform documentation describes a modular baseboard, expansion options and daughter cards. The official ecosystem includes Linux, RTEMS and hypervisors. Declared support must be checked against the versions actually delivered and the peripherals used by the application.

The NASA HPSC white paper also discusses power management and partitioning: available processing capability changes with the mission phase. Software therefore needs explicit operating transitions, priorities and degraded modes.

Five activities provide a useful engineering verification path:

Define expected fault behavior. Establish which functions must continue, which may stop and which require transition to a safe state.
Separate workloads and domains. Allocate control, communications and payload processing; configure access rights, DMA, interrupts and timing budgets.
Measure beyond averages. Capture peak latency, missed deadlines and energy use during contention, memory corrections, timeouts and recovery.
Inject controlled faults. Exercise corrupted data, stalled peripherals, resets and interrupted transfers; verify telemetry, state consistency and restart behavior. Such tests assess recovery logic without replacing physical irradiation.
Make configurations reproducible. Track the BSP, toolchain, boot images, ECC and isolation settings alongside each test result.

In practical embedded firmware and Linux integration work, hardware availability must be accompanied by software that can be measured, observed and recovered.

The engineering significance of this milestone

Early PIC64-HPSC1000-RH results bring a platform combining vector processing, fault management and onboard connectivity closer to practical integration. For an actual project, the next step is to connect characterization reports to mission requirements and verify the entire chain: processor, memory, power supplies, board and software.

The decisive question is which function the system continues to perform, with what timing and data quality, when an error occurs. That is the engineering measure of the value of greater computing capability in space.

Technical sources

Primary sources are linked throughout: Microchip announcements and documentation, NASA Radiation Hardness Assurance material, and ESA and ECSS references on radiation effects in semiconductors. The program update is dated October 27, 2026. Specifications should be checked against the variant and revision applicable to the design.

Originally published on Silicon LogiX.

Photovoltaics and EV charging: EEBUS and embedded Linux in SLX SolarPilot

Marco — Tue, 27 Oct 2026 18:09:57 +0000

The oven is switched on, solar production drops and the car is charging. These actions involve different parts of the home, yet meet in the same electrical balance. An energy management system needs to know available power, respect device limits and decide which requests can adapt. Testing those decisions requires a coherent model and communication that can be observed through to its result.

SLX SolarPilot connects a virtual residential plant to a Linux touch controller. The Windows simulator reproduces photovoltaics, storage, appliances and EV charging; the embedded application uses LVGL on Raspberry Pi and exchanges data through EEBUS. The bench makes it possible to study calculations, protocols and operator interaction together.

The SolarPilot project page presents the application and architecture. This article examines physical quantities, communication choices and criteria for verifiable testing. The GitHub repository and Windows release 0.4.5 are available for evaluation.

kW and kWh: two different questions

Power describes the rate of energy transfer at a given instant. Energy accounts for that transfer over time. A demand of 2 kW maintained for half an hour corresponds to 1 kWh: 2 kW × 0.5 h = 1 kWh. When a load changes, power must be integrated over the different intervals.

The SolarPilot engine uses a one-second physical step. An interval at constant power P, expressed in watts, contributes energy according to ΔE [Wh] = P [W] × Δt [s] / 3600. A 2000 W load maintained for 180 seconds therefore transfers 100 Wh. This simple check helps reveal unit errors, conversions applied twice and intervals counted beyond the end of a charging session.

Installed photovoltaic power, expressed in kWp, is another quantity: it describes module nameplate capacity under test conditions. It does not establish the energy produced in a day or guarantee constant operating power.

From sunlight to power available in the home

Photovoltaic modules generate DC electricity. The inverter converts it for the AC side of the installation. Irradiance on the module plane, orientation, inclination, cell temperature and converter limits contribute to the result. The JRC's PVGIS calculation methods describe these factors and distinguish module temperature from air temperature.

A simplified educational relationship is Pdc ≈ Pstc × (G / 1000) × [1 + γ × (Tcell − 25)]. G is irradiance in W/m², Tcell is cell temperature in degrees Celsius and γ is the module temperature coefficient. Reference conditions use 1000 W/m² and a cell temperature of 25 °C. The relationship helps interpret the phenomena; it does not replace a complete component model.

Sixteen 450 Wp modules provide 7.2 kWp of nameplate capacity. Assuming, solely for this illustrative calculation, G = 800 W/m², Tcell = 45 °C and γ = −0.0035 per degree, the temperature factor is 0.93 and estimated DC power is approximately 5.36 kW. These are declared assumptions, not a forecast for a particular roof or commercial module. Sandia's PVPMC description of PVWatts examines models based on irradiance and temperature.

The inverter adds its own constraint. If available DC energy would support power above the AC limit, output is capped: this is clipping. Module capacity, inverter rating and storage capacity must therefore remain separate parameters. SolarPilot's instantaneous model is deterministic and simplified: it projects solar components onto panels and applies temperature factors and limits, without calculating detailed local shading, electrical strings or complete MPPT tracking.

PVGIS: a historical reference with retained parameters

PVGIS provides photovoltaic data and production estimates for declared locations and configurations. The project includes reference responses for Bologna, Rome and Palermo: 1 kWp on the south-facing group, an inclination of approximately 26.565°, the SARAH3 database and system losses set to 14%. The monthly view scales them by the south-facing group's nameplate power.

These data do not change automatically when an object rotates in the scene, do not estimate the north-facing roof section and do not predict a cloud passing in the next few seconds. Instantaneous simulation remains a separate path. The declared 14% is already included in the PVGIS response: subtracting it again would reduce the result twice. The official losses FAQ also explains why successive loss factors combine multiplicatively.

The balance must close at every interval

The AC household model adopts an explicit convention: grid power is positive when importing and battery power is positive when discharging. Battery charging and grid export are negative. The fundamental numerical check is:

Ppv + Pgrid + Pbattery − Phome − Pev = 0

EV consumption is separate from household consumption. Inverter and battery power refer to the AC side of the balance; storage losses are accounted for when energy moves into or out of internal storage. This makes it possible to check both power conservation at the household node and the evolution of state of charge.

Illustrative AC power balance. Household demand, EV charging and battery charging total 6 kW; grid exchange is zero. The image uses Italian labels and is not an electrical wiring diagram.

In this example, 6.0 − 2.9 − 0.8 − 2.3 = 0 kW. Adding a 2.4 kW oven while keeping EV charging unchanged has a physically possible solution: reduce battery charging from 2.9 to 0.5 kW. Other priorities may instead reduce vehicle charging or allow grid import. The balance identifies admissible solutions; the policy chooses which to pursue.

An import limit cannot make appliance demand disappear. If non-deferrable loads exceed available headroom, the overload and intended behaviour must be represented. In the demonstrator, a protected cycle already running may continue while the EMS reduces new starts or flexible loads.

Storage: capacity, power, reserve and efficiency

A 10 kWh battery and a battery capable of supplying 3 kW describe two different constraints: storable energy and transferable power. SOC, State of Charge, represents a fraction of capacity. At 55% of 10 kWh, the model represents 5.5 kWh stored; with a reserve set to 15%, 4 kWh can be used before reaching that reserve.

SolarPilot applies 95% efficiency in each direction in its base configuration. Charging at 2 kW for half an hour draws 1 kWh from the AC side and adds 0.95 kWh to storage. Removing 1 kWh from internal energy delivers 0.95 kWh to the AC side. A full cycle under the same conditions therefore has efficiency 0.95 × 0.95 = 0.9025, or approximately 90.25%.

The reserve enters the calculation before the transfer is applied. In the example with 4 kWh of usable internal energy, the AC side can receive 3.8 kWh at 95% efficiency. A constant 0.8 kW load would correspond to 4.75 hours, only under these assumptions and with no other consumption. This is an exercise on the model, not a real home's autonomy estimate.

Near SOC limits, control must reduce the final transfer to what remains possible. Simply clipping SOC after an excessive step would distort accounting: the meter would have observed energy the battery could not accept or supply. Independent numerical tests cover these cases as well.

EV charging: energy target and available time

The bench vehicle has a demonstration capacity of 60 kWh. Moving from 45% to 80% requires 60 × (0.80 − 0.45) = 21 kWh of internal energy increase. With 92% charging efficiency, the required AC energy in the model is approximately 21 / 0.92 = 22.83 kWh.

At 16 A in a single-phase example at 230 V and unity power factor, power is 3.68 kW. At constant power, 22.83 kWh would take approximately 6 hours and 12 minutes. These are idealised conditions: the model does not represent a commercial vehicle's complete charging curve, final taper or IEC 61851 electrical control.

The demonstration minimum is 6 A, corresponding to 1.38 kW at 230 V; strategy increments correspond to 1 A. The limit can depend on the wallbox, available power, selected mode and target. Surplus, fast and departure modes allow different priorities to be compared. A feasibility check flags when available time and power are insufficient, without guaranteeing future solar production.

The final second matters too. If the vehicle reaches its target during an interval, the step's average power and actual charging duration must remain consistent. The core distinguishes active setpoint, active duration and stored energy, avoiding energy transfer beyond the target.

Appliances: managing a cycle, not just a switch

A washing machine does not continuously draw its heater's rated power. In the model it moves through filling, heating, washing, rinsing and spinning; a dishwasher has its own sequence. The EMS must account for the fact that authorising a low-power phase now may commit higher power shortly afterwards.

Control distinguishes new deferrable starts from protected cycles. Priorities and operating windows govern admission; explicit device unavailability differs from a simple reduction in surplus. The oven, kettle and cooktop help reproduce rapid changes and cases where available flexibility is insufficient.

The 3D scene makes the object associated with a load recognisable. Geometrically opening an appliance door remains a visual function: it does not automatically introduce a thermal model of an open door or consumption measured on a real appliance.

EEBUS: from device discovery to an operational connection

The bench's native communication uses SHIP 1.0.1 and SPINE 1.3.0, with Enbility library revisions pinned in the project. Their responsibilities differ: SHIP establishes and protects the connection; SPINE describes energy resources and application operations. The official EEBUS catalogue collects specifications, schemas and use cases. Using these layers requires commissioning and tests of roles, functions, limits and timing; the demonstrator does not claim certification or universal compatibility.

Discovery, addresses and trusted identity

Discovery uses mDNS/DNS-SD advertisements of the _ship._tcp service. A manually configured address can also locate a node. In the SolarPilot bench the configured SHIP ports are 4712 for the PC and 4713 for the controller: these are installation choices, not universal EEBUS port assignments. An IP address locates the partner but does not authorise it.

The bench records the peer's SKI, certificate fingerprint and SHIP ID. Connection setup proceeds through TCP, TLS and WebSocket before SHIP completes the application connection process. Pairing requires confirmation of the selected partner's identity; discovering a device on Wi-Fi is not enough to trust it. The SHIP overview and ship-go implementation describe this layer. No claim is made that every optional SHIP pairing or PIN path is implemented by the bench.

SPINE entities, features and roles

SPINE organises a device into entities and features with application roles. A role belongs to a feature; it is not determined simply by which endpoint opened the TCP connection. Discovery through nodeManagementDetailedDiscoveryData identifies the supported structure and functions before the controller assigns an installation role.

The SLX reference profile includes grid, household, PV, battery, EVSE, washing machine, dishwasher and available-PV entities. Its fixed addresses support repeatable bench commissioning; a third-party device must be mapped from the inventory it actually exposes. Depending on the supported use case, binding and subscriptions establish relationships for commands and subsequent notifications. The SPINE description explains the application layer.

Requests, notifications and correlated results

A SPINE datagram separates a header from the payload. Source and destination addresses identify the participating features; the command classifier distinguishes operations such as reads, replies, notifications and writes. msgCounter identifies an application message, while msgCounterReference links a response to its request. These are application counters, not TCP sequence numbers.

The spine-go datagram types document these fields. Correct correlation allows the controller to follow a write to its result even when notifications for other measurements arrive in between.

Measurements: number, scale, unit and origin

The MPC path, Monitoring of Power Consumption, transfers updates through measurementListData. A value must be interpreted together with the point description: identifier, quantity, unit, timestamp and status. The following fragment illustrates a measurement element; it is not a complete datagram ready to transmit:

{
  "measurementId": 1,
  "value": { "number": 2530, "scale": 0 },
  "valueSource": "calculatedValue"
}

If the point description associates that measurement with power in watts, the value represents 2530 W. number=253 and scale=1 produce the same quantity. The structure is documented in spine-go's Measurement types. Bench data are marked as calculated: sending a simulator value through a real protocol does not turn it into a physical sensor reading.

LPC and LPP: a limit does not impose consumption

LPC concerns limitation of consumption; LPP concerns limitation of production. SolarPilot uses loadControlLimitListData to transfer caps for supported entities. The LPC specification describes direction, parameters and use-case behaviour. In the model, a consumption cap of 2000 W does not force a load to consume 2000 W: it limits its admissible demand.

The node receiving a write returns a correlated result. resultData.errorNumber=0 indicates application acceptance; actual behaviour is checked against subsequent measurements. For storage, reserve, SOC, available energy and local limits continue to constrain what can happen. Profile choices are described in the SolarPilot bench EEBUS contract.

Data expiry and the demonstrator watchdog

The reference controller rejects MPC measurements older than three seconds. In the complete SLX profile, all six external limits required by the bench must also be recent and the SHIP connection must be present. When valid control is lost, EV and battery operation are stopped in the model, while already-started cycles and the local export interlock retain their declared behaviour.

This three-second watchdog is a local demonstrator rule, distinct from the timers and state machines of normative use cases. Generic profiles use limits for individual entities and their associated durations; they do not require the SLX bench's six-channel sequence. Passing this test cannot establish full compliance for a regulated controller.

What the message monitor actually shows

The EEBUS monitor observes the SHIP application body at stack entry and exit points. Displayed JSON is therefore available to the application after secure-connection processing. It is not a PCAP capture: it does not show TCP headers, encrypted TLS records or every byte of WebSocket framing. Network captures and application traces answer different questions.

PC TX and EMS RX observations may refer to the same message seen at both endpoints. Counting them as separate telegrams would distort estimated traffic. SolarPilot retains a ring of 256 observations; a preview may be truncated at 16 KiB, while the byte count covers the complete observed body.

Timing also needs a definition. The local bench's RTT includes publication, reception, policy decisions and the return of limits: it does not measure only a packet's time in flight. Timestamps, SPINE counters, direction and result instead make it possible to reconstruct a test sequence and distinguish delay, missing response and accepted command.

SunSpec Modbus TCP: reading a telegram and discovering models

Modbus TCP transport uses an MBAP header and a PDU containing function and data. The Modbus Application Protocol V1.1b3 defines functions; SunSpec gives meaning to energy points. The SolarPilot server defaults to port 1502, configurable to 502 when required by external equipment.

Complete example: requesting the SunSpec signature

In the bench mapping, Unit ID 2 represents the grid meter and the SunSpec signature is at zero-based address 40000. An FC03 read of two registers can use the following educational request, with Transaction ID 42:

00 2A 00 00 00 06 02 03 9C 40 00 02

00 2A: Transaction Identifier, repeated in the response.
00 00: Protocol Identifier for Modbus TCP.
00 06: number of following bytes, including Unit Identifier and PDU.
02: Unit Identifier of the bench meter.
03: read holding registers.
9C 40: starting address 40000 in big-endian format.
00 02: requested quantity, two 16-bit registers.

The response containing the SunS signature is:

00 2A 00 00 00 07 02 03 04 53 75 6E 53

The byte 04 indicates four data bytes. 53 75 6E 53 represents the ASCII signature. The two examples are 12 and 13 bytes long respectively. Framing cannot, however, depend on a single receive call: TCP is a stream and may deliver a frame in several parts or several frames together.

Model chains, addresses and types

After the signature, each block declares its identifier and length. A client can locate a model, read its points or skip it if unsupported. A final register containing identifier 0xFFFF and a zero length closes the chain. Individual point addresses depend on preceding blocks: copying them from another inverter without discovery is fragile.

The SolarPilot server associates Unit IDs 1, 2 and 3 with PV, grid and storage. It exposes models 1, 101, 120 and 123 for the first; 1 and 201 for the second; and 1, 101, 120 and 124 for the third. These are demonstrator choices. The official SunSpec definitions and SolarPilot matrix make the mapping verifiable.

Representation can use scaled integers or floating-point points, each with its own type. The scale factor is a signed integer: real value = raw value × 10^SF. In the SolarPilot meter profile, W_SF=1 provides 10 W resolution; a raw value of −123 represents −1230 W, meaning export under the bench convention. Register quantisation does not alter the core's physical calculation.

Unavailable values must be distinguished from zero. For example, the 0x8000 sentinel for an int16 point is not a usable negative measurement. Client software may also display register numbering with a one-address offset from protocol addresses: the example's base address 40000 must be interpreted under the client's convention, rather than assumed from the text shown in its address field.

SunSpec controls, errors and storage behaviour

Writing a limit and checking its effect

The bench server accepts FC03/FC04 reads and FC06 or FC16 writes at implemented points. FC06 writes one register, FC16 a group; SolarPilot validates a multiple-register write before applying it, avoiding partial updates when values are inadmissible. Invalid functions, addresses or data produce Modbus exceptions rather than an application confirmation.

An exception response to function 03 uses function code 0x83, with its most significant bit set, followed by the reason. Codes 01, 02 and 03 mean illegal function, illegal data address and illegal data value respectively. A timeout instead means no useful response arrived within the client's deadline; it must not be recorded as a negative confirmation received from the device.

Modbus TCP follows a request/response model: the client schedules reads and checks Transaction ID, function, length and data quantity before interpreting registers. Reception time is not automatically the physical measurement timestamp. Polling frequency must therefore match data updates, network load and device behaviour.

For PV, model 123 includes WMaxLimPct and WMaxLim_Ena. The client must read the scale, convert the percentage into the point's representation, set the limit and enable it. A 50% limit on a 6 kW nameplate rating corresponds to a maximum of 3 kW; it does not guarantee that sunlight will make those 3 kW available. The model 123 definition documents the points.

Where implemented, a positive RvrtTms restores local control after that number of real seconds; zero retains the command in the SolarPilot mapping. A write acknowledgement must be followed by reading back parameters and measurements, also checking whether a stricter local limit prevents its effect.

Model 124 and the charge/discharge interval

In model 124, StorCtl_Mod enables charge and discharge controls; InWRte, OutWRte and MinRsvPct describe limits and reserve. In the SolarPilot mapping, enabled controls define the interval:

−InWRte × WChaMax / 100
    ≤ Pbattery ≤
 OutWRte × WChaMax / 100

With WChaMax equal to 3 kW, InWRte = 50 and OutWRte = −50, enabling both controls reduces the interval to −1.5 kW: a charging request under the bench convention. An impossible interval is rejected. SOC, reserve, energy availability and grid-charging permission remain model constraints; operational meaning must always be checked against target-device documentation and the model 124 definition.

SLX functions and connection security

The optional SLX Energy/1 extension uses a separate bank: Unit ID 10 and registers 60000–60007. Identification, EV setpoint, washing-cycle permissions and watchdog belong to this bench contract. They are not universal SunSpec points and are not required to use the standard PV and storage reads and controls that are implemented.

The demo uses ordinary Modbus TCP on the laboratory network, with access restricted to authorised bench systems. Modbus Security, which uses TLS and certificates, is a distinct profile. TLS on the EEBUS connection does not automatically protect the separate Modbus TCP listener.

Interoperability and failure testing

Compatibility requires a shared contract at several levels: transport, identity, application role, available models, units, writable points and temporal behaviour. The same protocol name on two datasheets is an initial condition, not a passed acceptance test. The EEBUS certification documentation distinguishes roles and verification paths.

Unexpected identity: a discovered device must not be paired without checking that it is the intended partner.
Missing or unavailable point: the interface must preserve that information instead of inventing a plausible zero.
Rejected command: the result must remain associated with the request that caused it.
Late response: measurement validity must be assessed using the data's time, not merely the presence of an open socket.
Reconnection: a restored connection and newly valid control require fresh, coherent exchanges.

The project also separates network protocols from its own inter-process connection: JSON Lines is used for local IPC to the protocol service; the accelerated laboratory retains a separate NNG/TCP/CBOR path. Third-party devices do not need these internal mechanisms to communicate through EEBUS or SunSpec. The service documentation defines that boundary.

Embedded Linux and LVGL: control moves onto the device

The controller uses a Raspberry Pi 3 Model A+ and a 10.1-inch touchscreen. Its image is built with Buildroot and retains the services required for networking, control, the interface, time and persistence. The project version uses Linux 6.12.61 and LVGL 9.5. Hardware, pages and responsibilities are detailed in the project description.

The HMI receives state from the application service and sends validated requests. Navigation must remain responsive during a Wi-Fi scan; a late response must not reopen a page the user has already left. Flow animation, confirmations and events make these system behaviours visible on the display.

Illustrative view of the PC-to-controller chain, with Italian labels. The plant is simulated on the PC; control and the interface run on the embedded device. EEBUS carries measurements and commands.

The comparison has two distinct timescales: physical model steps and the real time of networking, watchdogs and interaction. External tests run at 1×; accelerated scenarios belong to the local laboratory. A recording allows data and decisions to be reviewed while preserving that distinction.

Turning a demonstration into a repeatable test

A useful test declares its initial situation, action, expected result and quantities to observe. Resetting, keeping the same duration and using the same parameters allow policies to be compared without attributing operator-introduced differences to the controller.

Case	Introduced change	Check
Solar surplus	Production exceeds loads	Allocation between storage, EV and export; consistent balance
Clouds and new loads	Reduced production and an appliance switched on	Adjustment of flexibility and respect for available limits
Storage reserve	SOC close to the configured minimum	Limited final transfer and loss accounting
EV target	Target SOC reached within an interval	Partial stop without additional energy beyond the target
Communication loss	Measurements or commands become stale	Visible status, fallback behaviour and recovery

The published release's GitHub validation compiled the Windows interface and successfully ran nine test groups. The path covers independent energy calculations, scenarios, EMS, recording and protocols. Physical Raspberry Pi trials also demonstrate the prototype's bench connection; they do not automatically qualify all third-party energy equipment.

Software scenarios and reports describe the declared model. A real installation's production requires site and component data; field control requires specific adapters, protection and validation. Operational weather forecasts, tariff optimisation and advanced integrations are developments available on request.

Trying SolarPilot and planning an integration

The Windows x64 package is sufficient to begin: extract the complete archive and launch SLX-SolarPilot.exe with an OpenGL 3.3 driver. The repository includes the interface, SDK, documentation and core binaries; use is governed by the Silicon LogiX evaluation licence. Controller firmware is not included in the public Windows package.

Developing an energy controller, HMI or device adapter starts with equipment interfaces, installation constraints and cases to reproduce. A technical assessment request can identify devices to connect, quantities to control and conditions to verify. This provides a route from the demonstration bench to custom development.

Technical references

SLX AgriPilot: Drone Mission Software with C++20, PX4 and MAVLink

Marco — Wed, 21 Oct 2026 10:29:48 +0000

Agricultural drone software development connects mission planning, flight firmware, autopilot communication and sensor data management. For UAV manufacturers, integrators and survey system developers, the engineering challenge is to build a coherent workflow from a requested route to acquisitions and verifiable results. This requires expertise in C++, embedded firmware, protocols, control systems and operator interfaces.

SLX AgriPilot is the Windows platform developed by Silicon LogiX for building and verifying VTOL drone survey missions. It combines a 3D agricultural environment, route planning, execution with PX4 and Gazebo, telemetry and virtual image analysis. The 0.6.0 evaluation release is available on GitHub. Its architecture provides a technical case study of the software and embedded engineering required to develop UAV systems.

Developing UAV systems for manufacturers and integrators

A drone, payload or inspection platform needs a clear allocation of responsibilities across onboard firmware, an optional mission computer, the ground application and subsequent analysis. Adding a MAVLink interface, another camera or a survey algorithm introduces synchronization, state management and diagnostic requirements that cross component boundaries.

AgriPilot makes this work accessible through an agricultural use case: operators can change a plan, observe a simulated mission and trace results back to acquired data. This workflow supports technical discussions about PX4 and MAVLink integration, mission software, telemetry and sensor acquisition before adapting the system to a product. For a specific development project, the starting point is a technical assessment of firmware and interfaces, with explicit requirements, hardware constraints and verification criteria.

An architecture connecting mission, autopilot and data

AgriPilot comprises a native C++20 application, an SDK for external modules and a simulation backend. On the Windows PC, the operator configures the field, builds the plan, edits waypoints and inspects results and recordings. The Python bridge, MAVSDK, PX4 firmware compiled for SITL and Gazebo Harmonic run in WSL2 with Ubuntu 22.04.

The boundaries between these layers make their responsibilities explicit. A planning module proposes a route; the application checks whether it satisfies the declared constraints; the bridge configures and starts the mission; PX4 executes the autopilot logic; Gazebo integrates the aircraft dynamics. The interface displays recorded samples. Movement in the 3D scene therefore comes from an identified source, such as a simulated flight recording or a geometric preview.

Laboratory architecture. PX4 produces state estimates and commands; Gazebo provides the simulated physical state. The recording preserves both sources.

This separation also helps maintenance. A mission upload failure must be distinguishable from a simulator startup problem, stale position data or an unusable image. Each execution therefore has its own directory, diagnostics for each phase and the identities of the components used. Reference versions are pinned: PX4 1.17.0, Gazebo Harmonic and MAVSDK Python 3.10.2.

Drone mission software: C++20, OpenGL and the operator interface

The desktop software uses GLFW for its window and input, OpenGL 3.3 for rendering, Dear ImGui for panels and ImPlot for charts. C++ supports typed contracts across the mission model, session state, geometry and visualization, with explicit resource management. Managing process handles, graphics resources and files contributes to application quality alongside interface design.

The editor lets operators drag waypoints with the mouse, validate them and undo or redo changes. The plan being edited, the executed mission and a loaded recording have separate roles. During replay, display time is interpolated to make movement readable, while the original samples remain available for analysis. Editing a plan must preserve the history of a flight that has already been recorded.

Interface engineering centers on operator decisions: which module is selected, which locations will be observed, which data are missing and where evidence for a finding can be inspected. The same requirements arise in industrial HMIs, test instruments and supervisory applications.

3D model, kinematics and coordinate systems

The AP-01 model represents a three-rotor VTOL with two tilting front nacelles, a rear rotor, movable surfaces, landing skids and a gimbal-mounted camera. The glTF/GLB asset preserves hierarchies, pivots, materials and transformations. Rotating a nacelle must correctly move all its descendants; orienting the gimbal must also update the camera's optical frame.

This requires transformation matrices, quaternions and explicit axis conventions. The local scene uses metric coordinates with a positive vertical axis; Gazebo and PX4 NED estimates require declared conversions. The glTF export also has its own convention. Applying a conversion twice can reverse a movement; using the body pose instead of the sensor pose can displace the ground footprint. These boundaries are documented in the project's coordinate and API contract.

The inspection camera follows the drone and allows the operator to orbit around it. During replay with joint data, nacelle tilt and the displayed mechanical movements are associated with the Gazebo recording. Maintenance operations are geometric controls performed with the aircraft parked. Defining these relationships between objects, state and data sources is useful in any 3D interface connected to a technical system.

Model inspection in the application: geometry, hierarchy and moving components are accessible in the same environment used to plan and review missions.

Drone firmware: the PX4 autopilot, uORB and state estimation

PX4 is the autopilot stack integrated into the laboratory. The firmware acquires sensor information, estimates aircraft state, manages operating modes and conditions, and produces actuator commands. Work in this project covers integration, nominal aircraft configuration, mission management and recording verification. PX4 remains an identified upstream component: an AgriPilot C++ policy and a flight firmware modification are separate engineering changes.

PX4 modules communicate through uORB, an internal publish/subscribe system. A producer publishes data on a topic; other modules subscribe to the topics they need. This decoupling helps engineers reason separately about drivers, estimation, control and communications while defining messages, timestamps and responsibilities.

State estimation combines inertial measurements with other available observations. The PX4 EKF2 filter handles quantities such as attitude, velocity, position and sensor biases. An accelerometer alone cannot provide a stable position over time: errors and biases accumulate through integration. Measurement fusion, time alignment and observation quality checks therefore contribute directly to autopilot behavior.

Simplified functional chain of a PX4 autopilot. The mission supplies objectives; estimation, control and allocation determine actuator commands.

Controllers turn navigation objectives into motion and attitude requests. Control allocation then translates thrust and torque requests into commands compatible with motor and servo geometry. In a tiltrotor, nacelle position, orientation and control authority matter: a 3D model alone does not define those physical parameters.

From firmware on a PC to an embedded system

In SITL, firmware runs as a program on the computer. A physical flight controller introduces a microcontroller, peripherals and an operating system; many PX4 platforms use NuttX. Embedded development must address task priorities, latency, memory, interrupt handling and peripheral access within the constraints of the selected board.

An acquisition path may require SPI or I²C sensor drivers, UART connections for external devices and CAN interfaces for distributed nodes. PX4 CAN support illustrates why electrical connections and device protocols are part of integration. Rates, queues, timeouts and stale data handling must match the requirements: receiving a message does not by itself establish that its data are still usable.

For a product, these activities also involve board configuration, startup, diagnostics, firmware updates and error recovery. AgriPilot supports work on integration and mission logic first; adapting that work to specific electronics requires a dedicated verification campaign on the target hardware.

SITL and Gazebo: what calculates the movement?

Software-in-the-loop means executing control software connected to a simulated environment. In AgriPilot, Gazebo integrates the physical state of the nominal model, and PX4 receives the observations supplied by the simulation link. Actuator commands return to the model, closing the loop. The Windows renderer uses the resulting data to display the aircraft.

AP-01 has declared mass, inertias, motor characteristics and nacelle limits. Its three-rotor geometry is registered against the visual model; dynamic parameters remain nominal laboratory assumptions. The executed campaign covers takeoff, hover flight, mission traversal, return and landing. Cruise transition and the behavior of a real aircraft require additional models and tests.

A central requirement is to preserve commands, PX4 estimates and Gazebo physical state as separate data. If the estimated drone is close to the route while simulator ground truth differs, the comparison must expose that difference. Simulation time, elapsed PC time and message timestamps also have different meanings: confusing them changes synchronization and measurements. Runtime conditions and model and firmware identities are described in the runtime documentation.

MAVLink and MAVSDK integration: drone missions and telemetry

MAVLink defines messages and services for exchanging information with vehicles and components. In this laboratory it carries missions, telemetry, parameters and command outcomes. MAVSDK provides the APIs used by the Python bridge: AgriPilot uses MissionRaw to work with mission items, and subscriptions to monitor state changes.

The MAVLink Mission Protocol manages item transfer, sequencing and acknowledgment. The bridge also downloads an uploaded mission to check its contents. This verifies the handoff between the planner's proposal and the plan received by the autopilot before execution is considered.

Sending a command initiates a transaction. The Command Protocol provides a COMMAND_ACK response: its result must be interpreted together with the subsequent system state. For example, an arming request may be denied because preconditions are unmet. The project monitors telemetry continuity, transport availability, autopilot health and altitude stability; an eligible transient denial is handled through bounded retries and a fresh stability check.

This is an asynchronous state machine: backend readiness, connection, configuration, upload, verification, arming, takeoff, mission and shutdown. Each phase has entry conditions, timeouts and diagnostic outcomes. The bridge also manages cancellation and termination of its own processes while preserving logs. These skills transfer to industrial gateways and remote control systems, where sending, receiving and completing an action are separate events.

A real link also requires authentication, network segmentation and key management. MAVLink 2 message signing addresses protocol authenticity and integrity; transport encryption serves a different purpose. The laboratory backend is local. Protection of a radio network or remote access must be specified and verified in the operational integration.

Survey planning: geometry, coverage and the SDK

The planner receives the area, altitude, speed, pass spacing, orientation and camera parameters. The C++ examples build parallel transects, clip them to the polygon and alternate pass direction. The application adds takeoff, return and landing anchors and checks the plan's declared constraints.

For an ideal nadir-facing camera over flat ground, footprint width is W = h × s_w / f, where h is height above ground, s_w is sensor width and f is focal length, expressed in the same unit as s_w. Nominal ground sampling distance is GSD = W / N, where N is image width in pixels. Along-track capture spacing is d = H × (1 − o), with footprint length H along the route and longitudinal overlap o.

Ideal planning geometry over flat ground. Nominal coverage must be compared with images that were actually acquired, valid and sufficiently readable.

Reducing pass spacing can increase coverage while changing waypoint count, acquisition count and duration. Baseline and Dense make this choice comparable in the laboratory. The plan's nominal resolution and the analysis raster resolution have separate contracts: current virtual images have an analysis width of 96 pixels. A theoretical GSD value therefore does not establish the resolution of a real image.

The SDK exposes planning and telemetry observation as independent Windows executables. Modules receive and return versioned JSON through pipes. Time, message size and process resource limits contain failures; a SHA-256 checksum identifies the module used. This boundary avoids requiring a shared C++ ABI and supports implementation comparisons with an identifiable execution history.

Gimbal and acquisition: knowing where the sensor looks

The camera acquires from a composed pose: drone position and orientation, the mounting transformation and gimbal rotations. Pitch and yaw change the optical axis and where rays intersect the ground. A camera facing the sky cannot observe the field; an oblique camera produces a different geometry from a nadir-facing camera.

In AgriPilot this pose governs virtual image generation. The system preserves the origin, optical axes, sensor parameters and frame quality. RGB, NIR and thermal rasters come from a procedural optical model over a flat surface; these synthetic data are associated with the mission and inspectable in the interface. The gimbal thereby connects model kinematics to acquisition geometry.

Images and data available in the software. These four views refer to an identified virtual acquisition whose parameters and pixels are preserved.

Agricultural drone data analysis: RGB, NIR, thermal and NDVI

The laboratory includes four contexts: arable crops, irrigation, orchard and post-storm survey. The operator configures points with normal or problematic conditions, position, radius and intensity. During the mission, acquisitions observe only areas inside the valid footprint. Unobserved cells remain unknown.

The image generator knows the field conditions. The detector instead receives saved rasters, poses, declared calibration, area of interest and thresholds: it does not receive configured anomaly centers or intensities. Known conditions are connected later to evaluate errors. This architecture makes it possible to check whether changing pixels actually changes the result.

Scenario knowledge and observed data follow separate paths. Detection preserves the source frame link; evaluation subsequently compares results against known conditions.

NDVI is calculated as (NIR − R) / (NIR + R). In the software it contributes to a vegetation anomaly index; the irrigation scenario also combines a synthetic thermal contrast. Cells are projected into images and sampled only where valid pixels exist. Adjacent anomalous cells form findings linked to the first usable acquisition.

Context gives an indication its meaning: a low vegetation index alone does not identify an agronomic cause. The laboratory score does not represent a probability, moisture percentage or neural network confidence. Current processing uses explicit indices and thresholds; introducing machine learning models would require a dedicated dataset, annotations, metrics and validation.

Noise, exposure, haze, saturation and motion blur can degrade the modeled data. An excluded frame remains saved with its quality outcome. Unknown areas remain distinct from areas observed without anomalies, providing information needed to decide whether a survey is sufficient.

Recordings, before-and-after comparisons and reports

A result becomes useful when the path that produced it can be reconstructed. AgriPilot exports HTML reports, CSV, JSON, images, metadata and a SHA-256 inventory. Every finding links to source cells and frames; the mission preserves flight samples, parameters and the identities of firmware, model and modules. Original PX4 ULog files are retained separately from captured MAVLink datagrams.

A before-and-after comparison can involve a second mission after field conditions have changed. Threshold-only reanalysis uses the same original pixels. Regenerating images along a saved route has another provenance, declared by the software. Distinguishing these operations makes it possible to discuss what changed: environment, route, acquisition or algorithm.

Metrics also remain separate: mission progress and completion, route error, geometric coverage, optical coverage and detection quality. A mission can finish successfully while leaving parts of the field unobserved. Precision, recall and errors against known conditions describe the evaluated synthetic case without extending those numbers to real farmland.

Software verification and the path to hardware

Verification covers module protocols, failures and timeouts, plan validation, editor interactions, camera geometry, detector independence and export integrity. The Windows release has also been exercised with the PX4/Gazebo backend on the nominal three-motor model. Dependency versions, archive hashes, public source builds and CI checks make the distribution scope inspectable.

Moving to an operational drone requires further work: aircraft parameter identification, electronics selection and integration, sensor calibration, link verification, fault analysis and system tests. Hardware-in-the-loop runs firmware on a physical flight controller connected to a compatible simulation. It needs a campaign distinct from SITL, followed by the tests required for the product and its intended use.

The current laboratory supports development and comparison of missions, integrations and data processing within documented assumptions. Real-field multispectral calibration, RTK/DEM georeferencing, calibrated energy endurance, VTOL transition and HIL tests are possible areas of subsequent work, to be specified and verified. The model documentation defines the preview's scope.

Questions about drone software, firmware and simulation

What is the difference between mission software and drone firmware?

Mission software prepares routes, displays states and manages acquisitions and results. Flight firmware executes autopilot functions on the system controlling the aircraft. Integration connects objectives, commands and telemetry through defined interfaces; changes to a planner and changes to controllers require different verification activities.

What are PX4, MAVLink and Gazebo used for?

PX4 supplies the autopilot stack; MAVLink is the protocol used for missions, parameters, commands and telemetry; Gazebo executes the simulated physical model. AgriPilot integrates them with the Windows application and MAVSDK bridge. Recordings keep the requested plan, autopilot estimate and simulator state separate.

Can a custom camera or sensor be integrated?

This requires engineering around the interface, power supply, data format, trigger and timestamps. Calibration, mounting pose relative to the aircraft and sample validity conditions must also be defined. AgriPilot's virtual camera illustrates the data path; a physical payload requires dedicated drivers, integration and tests.

Does simulation replace real drone testing?

Simulation allows software and interfaces to be verified against a declared model. Real system testing must then address electronics, sensors, identified dynamics, operating conditions and fault behavior. SITL, HIL tests and product verification have separate objectives and acceptance criteria.

The engineering capabilities connected by this project

AgriPilot centers on integration work that connects requirements, architecture and evidence:

Software and HMI: C++ applications, editors, charts, 3D rendering and session management.
Firmware and control: autopilot stack integration, configuration, estimation, actuators and diagnostics.
Communications: protocols, transactions, state machines, synchronization and interruption handling.
Geometry and acquisition: coordinate frames, sensor poses, footprint, overlap and valid samples.
Data and verification: traceable algorithms, repeatable comparisons under declared conditions, logs and inspectable reports.

The Silicon LogiX approach connects requirements, firmware, management applications and data through defined interfaces and progressive verification. Work includes analyzing the required behavior, defining contracts, implementing the integration loop and testing against explicit acceptance criteria. The objective is to build components that remain integrable, diagnosable and maintainable as the product evolves.

The SLX AgriPilot GitHub page provides the Windows distribution, technical documentation and SDK examples. UAV integrations, custom payloads and management applications can be assessed through a technical discussion with Silicon LogiX. Engineering services include embedded firmware development, software development and hardware and software prototyping.

Canonical source: Agricultural Drone Software and Firmware: SLX AgriPilot.

EV charging explained: BMS, OCPP and SLX ChargeProof

Marco — Tue, 20 Oct 2026 09:54:25 +0000

The charger has ample rated power, the car is connected and the session is authorized. Yet charging slows down. The cause may lie in the battery, cooling system, cable or power available across the site. For engineers developing a BMS, charging station or fleet application, the useful question is specific: which constraint is limiting power, and will the vehicle be ready at departure?

I built SLX ChargeProof to explore that relationship in a desktop laboratory: change a condition, observe the system response and retain readable evidence. The project combines a C++20 electrothermal model, local OCPP 2.0.1 communication over WebSocket, an OpenGL 3D campus and tools for diagnosis, recording and replay. The Windows preview is available on GitHub. Batteries and chargers are simulated; the software and message exchanges run on the PC.

Why EV charging slows down

The kilowatt rating on a charger describes an infrastructure capability, not a power level guaranteed throughout a session. The Battery Management System, or BMS, determines acceptable charging conditions for the pack. The station must also respect its electrical limits, the connection limits and any power budget shared with other loads.

Understanding charging time requires distinguishing power, measured in kW, from energy, measured in kWh. Consider a simplified example: a battery with 75 kWh of usable capacity needs approximately 45 kWh to move from 20% to 80%. At an average power of 90 kW actually stored in the battery, that would take 30 minutes. An instantaneous peak of 180 kW does not, by itself, halve the estimate: what matters is the power sustained over the session.

Indicative time [h] = energy to store [kWh] / average stored power [kW]

This is an approximate calculation assuming constant usable capacity. If using grid input power instead, conversion losses and auxiliary loads must be accounted for. The US Department of Energy’s Alternative Fuels Data Center identifies capacity, state of charge, the vehicle and charging equipment among the factors that determine duration.

State of charge, or SOC, and temperature change during charging. As cells approach their voltage limits, current must decrease. A battery that is too cold or too hot may lead the controller to reduce its request further. The slower phase does not begin at a universal percentage: it depends on the pack and manufacturer’s strategy. A falling power curve can therefore indicate expected operation or a fault that needs diagnosis.

AC and DC charging: where conversion happens

A battery charges with direct current. In AC charging, conversion from alternating current takes place in the vehicle’s On-Board Charger, or OBC. In DC charging, the main conversion happens outside the vehicle. Texas Instruments’ technical documentation on EVs and EVSE explains this distinction and the role of communication between the vehicle and infrastructure.

Two paths for delivering energy to a battery

Aspect	AC charging	DC charging
Main AC/DC conversion	On-board vehicle charger	Power electronics outside the vehicle
A constraint to check	OBC capability and available supply	Station, cable and battery voltage/current operating ranges
Application context	Dwell times compatible with OBC power	Sessions requiring higher power, within system limits

Voltage has practical consequences too. In an ideal comparison at 200 kW, 400 V requires 500 A and 800 V requires 250 A. With the same resistance in the conductor being considered, halving current reduces its I²R losses to one quarter. This does not imply that all vehicle losses fall by the same amount: components, conversion stages, insulation and operating conditions also change.

The Combined Charging System, CCS, concerns charging interfaces and their interoperability. OCPP addresses a different software connection. Recognizing these layers prevents attributing charger or vehicle functions to the wrong protocol.

BMS and electrothermal modeling: connecting current, SOC and temperature

In a real system, the BMS collects voltage, current and temperature measurements, estimates states such as SOC, and applies protection and operating limits. A sensor reading does not automatically represent every point in the pack. A measurement that appears valid can still be unrepresentative, offset or stuck.

ChargeProof makes these relationships observable through a Thevenin equivalent circuit: an SOC-dependent open-circuit voltage, resistance and an RC branch for transient response. The model updates charge, polarization and thermal behavior at a fixed step of 0.5 virtual seconds. The PyBaMM Thevenin model documentation provides a reference for this type of formulation. PyBaMM is not a runtime dependency of ChargeProof.

The preview offers three synthetic profiles: a compact LFP vehicle, an 800 V-class NMC SUV and an LFP van. They are declared engineering assumptions for comparing behavior and constraints, not data from commercial vehicle models. Two representative aggregates separate the main pack population from a weak block. The many cells visible in the scene do not each have an independent thermal model.

This design exposes a clear causal chain: cooling changes, calculated temperature changes, accepted current changes, and the energy that can be stored before departure changes. DOE research on fast-charging technology gaps illustrates the interaction between transport, temperature and electrochemical processes. The demonstrator simplifies those processes and does not calculate electrochemical cell degradation.

OCPP, ISO 15118 and Plug & Charge serve different roles

OCPP connects a charging station to its Charging Station Management System, or CSMS. The ISO 15118 family addresses communication between the vehicle and EVSE, the equipment supplying energy to the vehicle. Keeping those two connections separate is essential when designing authorization, control and diagnostics.

The charging chain and the scope of the ChargeProof preview

Layer	Purpose	In this preview
Vehicle / BMS	Charging request and battery limits	Numerical emulation with synthetic profiles
Vehicle ↔ EVSE	Charging communication, including ISO 15118	No ISO 15118 stack
EVSE ↔ CSMS	OCPP authorization, status and transactions	OCPP 2.0.1 subset over local WebSocket
Plug & Charge	Automatic identification using certificates and a trust infrastructure	Not implemented

In the laboratory, the station client and local server actually exchange JSON messages: BootNotification, Heartbeat, Authorize, StatusNotification and TransactionEvent, with meter values included in transaction events. Requests and responses can be retained and associated with their session. An OCPP authorization message is not a Plug & Charge procedure.

As CharIN explains in its Plug & Charge overview, automated identification involves standardized interfaces and security mechanisms. A working integration must handle certificates, trust chains and credential lifecycles. The preview includes neither this PKI nor a TLS connection to an external backend: its evaluation CSMS listens only on the PC’s loopback interface.

The Open Charge Alliance documents OCPP 1.6, 2.0.1 and 2.1 and their functions. ChargeProof uses the 2.0.1 subset described in its protocol coverage documentation. It does not claim a complete standard implementation or OCA certification.

Smart charging: site power limits and departure times

At a depot with several vehicles, sessions compete for a shared resource. The sum of charger ratings may exceed the power that the grid connection can supply. Battery requests, station availability and auxiliary loads must therefore be coordinated.

ChargeProof distinguishes the EV/BMS request, station command and power actually delivered. These quantities can differ. A BMS may accept substantial power while the site allocates less; a station may receive a high command while a cable limit imposes a reduction. Once expressed at the same electrical boundary, applied power must remain within every constraint.

The demonstration controller uses max-min fair allocation: it shares the available budget among admissible requests and redistributes unused allocations. Conversion and auxiliary loads are accounted for before assigning DC power. This is not an economic fleet optimizer: tariffs, real duty cycles, photovoltaics and active battery storage require a dedicated project.

The departure forecast adds an operational question to instantaneous power. It runs an isolated copy of the model while holding current assumptions about faults, authorization, ambient conditions and site budget constant. It describes what would happen if those conditions persisted; it does not anticipate a recovery action that the operator has not yet performed.

ChargeProof’s technology: C++20, OCPP and native graphics

The opening ChargeProof Studio page presents the four software layers and connects each to an observable check. The 3D scene, messages and reports refer to the same session. Users can move from “why is charging slowing down?” to the numerical constraint and its recorded evidence.

Actual screenshot of the Windows preview. ChargeProof Studio connects the technologies to their functions and offers a guided diagnosis of SUV cooling.

C++20 core and versioned SDK. Computation runs in a separate process connected to the desktop through private pipes. The same core supports interactive sessions and headless scenarios.
GLFW, Dear ImGui docking and OpenGL 3.3. GLFW manages the window and graphics context; Dear ImGui builds the technical panels; OpenGL renders the campus, inspection views and live displays. The application is a native C++ desktop.
OCPP 2.0.1 and WebSocket. A WinHTTP client and WinSock server perform the local exchange, making the actual transmitted messages available for inspection.
Recordings and reports. Events, inputs, states and results remain associated with a session, with HTML, JSON and CSV exports for analysis and comparison.

The campus has five inspectable bays. Three have operational electrical profiles; the bus and truck are inspection geometries. Visualization helps locate what is being observed, while the model documentation explains which states are actually calculated.

An experiment: from a 72% forecast to an observed 80%

The guided diagnosis starts with a synthetic SUV at 25% SOC and 48 °C, targeting 80% after twenty virtual minutes, with a 500 kW site AC limit shared by the enabled sessions. These values define a demonstration experiment, not operating instructions for a real battery.

Following authorization, the nominal forecast indicates that the target is reachable. The guide then introduces degraded cooling and keeps it active until the ten-minute checkpoint. The model reduces acceptable power and the departure forecast drops to approximately 72%. Restoring cooling brings the forecast back to 80%. The simulation continues and also retains the SOC actually integrated at departure.

Guided scenario results and their assumptions

Diagnosis stage	Indication	Interpretation
Nominal conditions	80.0% forecast	Target reachable if current conditions persist
Fault, at minute 10	Approximately 72.0% forecast	Departure estimate if cooling remains degraded
After recovery	80.0% forecast	Updated estimate with cooling restored
Departure, at minute 20	80.0% observed in the model	Result of the simulation that included recovery

Actual result of the simulated case. The screen separates the nominal forecast, fault forecast, forecast after recovery and final SOC. The 72% value is a conditional estimate, not the final outcome of the run that restored cooling.

The useful comparison is between cause, consequence and intervention. The final 80% value alone would hide the problem encountered during the session; a cooling alarm alone would not quantify its effect on the departure target. Retaining both helps explain controller behavior and the timing of an effective recovery.

Faults, messages and energy accounting: interpreting the evidence

The preview includes backend loss, sensor offset, degraded cooling, reduced power-module output, a weak battery block and cable heating, plus a stuck-sensor variant. Each scenario exposes a different system boundary.

The sensor case separates calculated physical temperature from the value received by the controller: adding a measurement offset does not artificially change the thermal state. The backend scenario disconnects the actual local socket. Existing authorized transactions may continue under the demonstration policy, while new authorizations are rejected until recovery. Events are queued in memory for subsequent delivery; the queue is not persistent storage that survives a program crash.

The operational laboratory view at the end of the guided scenario. Campus, inspector and timeline show the same session state. Thermal colors represent the model aggregates, not measured thermography.

Energy accounting also requires clear boundaries. The software distinguishes AC input, DC pack-terminal energy, stored energy, losses and auxiliaries. The meter register carried in the demonstrator’s messages refers to the pack’s DC terminal and is not a revenue meter. Closing the energy ledger checks the model’s internal accounting; it does not demonstrate that its parameters describe a real battery.

The published version’s automated checks compiled the Windows desktop and ran seven headless scenarios, checking site constraints, energy balances and transaction lifecycles among other properties. The validation documentation describes the scope and limits of these checks.

Replay reads a recording without advancing the model or sending new messages. A new simulation recalculates behavior from its inputs. The included A/B comparison uses the same controller build and a fault-free baseline. Comparing two firmware versions would require a separate campaign retaining the respective binaries and configurations.

MCS and V2G require separate engineering work

Heavy-duty charging changes the scale of the problem: more energy to transfer, constrained dwell times and greater demands on conductors, contacts and cooling. The Megawatt Charging System, MCS, described by CharIN addresses interfaces for these applications. Increasing a kW setting in a simulator is not sufficient to represent those characteristics.

Vehicle-to-Grid, or V2G, adds energy transfer from the vehicle to the grid. ISO 15118-20:2022 also defines messages and sequences for bidirectional power transfer. Its 2026 amendment addresses additional services, including MCS and an updated security concept. Communication is one part of the design: bidirectional power electronics, control and grid-interface requirements must also be addressed.

These functions are not operational in the ChargeProof preview. The same applies to ISO 15118, Plug & Charge, OCPP 2.1 and external CSMS connections. Discussing them alongside the demonstrator places charging technology in context while keeping the executable scope clear.

How to try SLX ChargeProof on Windows

Open release 0.1.0-preview-r5 and download SLX-ChargeProof-0.1.0-preview-r5.zip. Extract the entire archive and start SLX-ChargeProof.exe, keeping the executable, assets, core and licenses together. Windows 10/11 x64 and an OpenGL 3.3 graphics driver are required. The release includes SHA-256 checksums and is an unsigned evaluation preview.

Choose Start guided diagnosis to follow the SUV scenario’s checkpoints. After the final result, open the report, inspect the messages or move to the free laboratory. The portable package requires no compiler, Python installation, account or charging hardware.

The public slx-chargeproof repository includes interface and adapter sources, the SDK and documentation. The proprietary numerical core is supplied as an evaluation binary. Terms are set out in the Silicon LogiX Evaluation License 1.0; third-party components retain their own licenses. Use the portable ZIP to run the application directly and the source archive to rebuild the interface.

From a virtual laboratory to a real charging system

ChargeProof supports discussions about architecture, diagnosis and test criteria before connecting a physical bench. A specific project needs cell and pack data, OCV and resistance curves across SOC and temperature, cooling-system characteristics, electrical limits and interface requirements. Comparison with measurements and tests in a defined operating envelope is necessary to qualify a model for that use.

These inputs support the development of BMS and EVSE firmware, protocol adapters, operator interfaces and software-in-the-loop or hardware-in-the-loop test campaigns, with explicit targets, clocks and acceptance criteria. A simulator using synthetic parameters does not replace electrical, thermal, interoperability or product-safety testing.

The approach is shared by SLX CellProof’s robotics laboratory and the industrial SLX GridPilot OPC UA laboratory: make behavior explorable and retain the link between inputs, events and outcomes. For a custom charging solution, the starting point is to define the problem to investigate and the available data with Silicon LogiX.

Frequently asked questions about EV charging simulation

Why does a car draw less than the charger’s rated power?

The rating is an infrastructure limit. The battery may request less current because of SOC, temperature or cell voltage. Cable, station and site limits may also intervene. ChargeProof separates request, command and delivered power so the active constraint can be observed in the model.

Are OCPP and ISO 15118 the same thing?

No. OCPP connects a station to its management system; ISO 15118 concerns communication between the vehicle and charging infrastructure. The preview executes an OCPP 2.0.1 subset locally and includes neither an ISO 15118 stack nor Plug & Charge.

Can I use ChargeProof without a vehicle or charging station?

Yes. The Windows preview runs on a PC with synthetic models and a local CSMS. The guided diagnosis demonstrates faults, forecasts and recovery without connected equipment. It does not control a real vehicle or charger.

Does a positive forecast guarantee the result on a real battery?

No. The forecast applies to the model and its stated assumptions. Synthetic profiles and consistent numerical accounting are not experimental calibration. Real-world use requires representative data, a defined validity envelope and a dedicated verification campaign.

Technical references and further reading

These sources explain the technologies discussed. The software’s executed scope is documented separately in the repository. References checked on 20 October 2026.

The cover is a generated editorial illustration; the three figures in the article are actual screenshots of the preview.

DOE / AFDC — Electric Vehicle Charging Stations: infrastructure and factors affecting charging time.
Texas Instruments — EV/EVSE communication and architecture: AC/DC conversion and vehicle-station communication.
Open Charge Alliance — Open Charge Point Protocol: OCPP roles and versions.
CharIN — CCS, Plug & Charge and MCS: charging interfaces and interoperability.
ISO 15118-20:2022 and Amd 1:2026: second-generation communication and additional services.
DOE — Extreme Fast Charging Technology Gap Assessment: physical and thermal challenges of fast charging.
PyBaMM — Thevenin Model: a reference for the equivalent-circuit model family, not a program dependency.
GLFW and Dear ImGui: libraries used by the native desktop.
ChargeProof model, protocol coverage and preview validation: the project’s documented formulation, assumptions and checks.

Originally published on Silicon LogiX: EV charging explained: BMS, OCPP and SLX ChargeProof.

SLX EchoBench: ultrasound, firmware and FPGAs in a 3D laboratory

Marco — Mon, 19 Oct 2026 11:43:39 +0000

A FIFO fills up, some samples are lost, and a perfectly plausible echo remains on the screen. The firmware can still find a peak above the threshold and report an indication: the peak exists, but the acquisition is incomplete. This is a case where digital electronics, embedded software and signal analysis need to share the same understanding of the data.

I built SLX EchoBench to make this problem explorable through a virtual ultrasonic inspection bench. Behind the 3D scene are a C++20 engine, ARM firmware running Eclipse ThreadX, the Renode emulation platform and a FIFO described in SystemVerilog and executed through Verilator. The project connects an operator interface, synthetic data and joint verification of firmware and digital logic. The Windows preview on GitHub runs offline.

FPGAs: building a data path in programmable logic

FPGA stands for Field-Programmable Gate Array: an integrated circuit whose logic resources and interconnections can be configured after manufacture. Registers, memories and combinational functions can implement dedicated digital paths, with multiple operations active in parallel. AMD's introduction to programmable logic explains this principle and its use in data processing.

In a measurement chain, an FPGA can receive samples from an analogue-to-digital converter, synchronise channels, manage buffers and process data through pipelines. Processor firmware can handle configuration, state management and higher-level decisions. The boundary between these responsibilities becomes part of the design: which data is ready, when it can be read and how errors are communicated.

The EchoBench model uses a nominal sampling rate of 25 million samples per second: one sample every 40 ns. This timescale helps explain why buffer capacity and flow control matter. The rate describes the synthetic signal; the speed at which a PC executes the demo is a separate measurement.

RTL and SystemVerilog: describing circuit behaviour

RTL, or Register Transfer Level, describes logic through registers, operations and transfers governed by a clock. Hardware description languages such as VHDL, Verilog and SystemVerilog express these circuits. Implementing them on an FPGA then requires synthesis, implementation and timing verification for the selected device.

EchoBench's RTL block is a synchronous FIFO holding 256 words of 16 bits, written in SystemVerilog. FIFO means First In, First Out: the first item written is the first available to read. Pointers, occupancy, availability signals and a dropped-data counter provide a small but meaningful example of a component used in acquisition paths.

Verilator compiles Verilog/SystemVerilog descriptions into executable C++ or SystemC models. EchoBench uses the compiled FIFO model in a native library: reset, writes, reads and overflow pass through that logic. This verifies RTL behaviour; the preview distributes an executable model rather than a bitstream for a physical FPGA board.

From the virtual bench to the ultrasonic signal

The scene represents an inspection bench with a movable probe and a reference specimen. The model implements a normal-beam pulse-echo measurement: it generates the pulse, reflector echoes and backwall echo, linking them to probe position and configuration. The demonstration specimen is 40 mm thick and contains three known reflectors.

Each acquisition contains 512 samples at 25 MS/s, with a nominal 5 MHz pulse. Gain, filtering, noise, attenuation and coupling let the operator explore changes in the signal and its usability. This is a simplified synthetic acoustic model, described in the architecture documentation: results apply within those assumptions and support development and discussion of the processing workflow.

A real demo screenshot: probe position, signal and maps refer to the same acquisition in the session. Grey map areas are unsampled points.

A-scan, B-scan and C-scan: reading the same acquisition

The A-scan shows the signal over time as RF or an envelope. Two time windows, called gates, define the regions of interest: in the included configuration, gate A looks for internal echoes and gate B observes the backwall echo. Amplitude, time of flight and estimated thickness remain associated with the position and configuration used to acquire the point.

The B-scan places envelopes side by side along the selected pass; the C-scan maps amplitude, thickness or acquisition quality onto the sampled surface. Scanning can be manual or follow a raster. The interface moves between the overall view and signal detail, lets the operator stop the experiment and returns to recorded points.

Data quality and the extent of the sampled path describe different aspects of the inspection. Insufficient coupling, saturation and sample loss can make a point not evaluable. The maps describe surface acquisitions in the model; an area traversed by the probe does not, by itself, establish ultrasonic coverage of the volume.

Known references and model calibration

The reference view reveals the synthetic reflectors inside the specimen. It connects the geometry to the observed echo, supports experiments with different positions and helps explain the cause of an indication. The geometric reference therefore keeps an explicit role throughout the experiment.

Known reflectors highlighted in the scene. The gate A peak is still present, but the acquisition is marked not evaluable because the host model has lost 64 samples.

Setup & calibration includes two synthetic references, 20 and 40 mm, used to derive the model's velocity and time offset. Configuration and calibration are preserved with the results. This verifies software behaviour under the declared conditions; calibrating a physical instrument requires specific references, procedures and checks.

ThreadX and Renode: firmware inside the virtual platform

Eclipse ThreadX is an RTOS, a real-time operating system for embedded applications. It provides threads, scheduling, synchronisation and timing services. In EchoBench, an acquisition thread reads samples and peripheral status, finds the maximum within the gate and writes its result to a memory area shared with the test environment.

The two compiled ARM firmware builds execute in Renode on a virtual Cortex-M3 platform. The platform includes memory, a SysTick timer and an acquisition peripheral implemented in C#. The processor uses memory-mapped I/O, or MMIO, to access registers: COUNT gives the available sample count, DATA returns the next sample and FLAGS reports data loss.

In the RTL profile, the C# peripheral calls the FIFO library compiled with Verilator. This connects executed ARM instructions, register accesses and digital logic behaviour. The Renode peripheral modelling guide explains the general bus access mechanism; the EchoBench documentation describes the specific connection used in the demo.

The experiment: the same peak, different decisions

Both builds receive the same saved samples. In the included profile, the gate operates on Q15 samples at 0 dB with no filtering. Their difference is deliberate: A ignores the overflow admission check and can accept the remaining peak; B checks data completeness and rejects the incomplete acquisition. This makes a data-admission error observable even when the amplitude still looks plausible.

The evidence panel collects compiled RTL processing results, input identity and RTOS ticks. Build A's result is visible here; the complete comparison also verifies that B rejects incomplete data.

To reproduce the problem, the ThreadX + Verilator FIFO profile can attempt to write a burst of 512 words into a 256-word FIFO before reading its contents. It retains 256 words and counts 256 attempted writes as lost data. A peak in the retained portion can therefore survive the fault: A accepts it, while B also considers the loss flag and sample count. The host model fault has a separate contract and drops 64 samples.

The ready/valid signals also make this useful for FPGA developers. An input transfer is accepted when the producer presents valid data and the FIFO is ready to receive it. Readiness enables flow regulation through backpressure. The overflow test deliberately forces attempts while the queue is full and verifies that data-loss information reaches the firmware decision.

Firmware execution processes the single selected saved input; the raster acquisition and maps are handled by the host model. Results preserve hashes of the input, firmware and RTL, together with the ThreadX ticks actually observed. Timing and peripherals belong to the emulated platform and require dedicated validation before drawing conclusions about a physical board.

Godot and C++20: connecting the 3D bench to processing

The visible laboratory uses Godot 4.5 and GDScript for the 3D scene, operator controls and result inspection. The bench makes the relationship between probe position, configuration and signal easy to explore: moving the probe changes the model's data and the context in which it should be interpreted.

The C++20 engine manages the acoustic model, processing, sessions and emulation jobs. Interface and engine communicate through a local API using JSON messages; Renode runs as a separate process, with cancellation support. This keeps controls responsive during firmware comparison and preserves the input, configuration and outcome together.

Repeating experiments and preserving evidence

A session saves samples, probe poses, applied parameters, calibration, events and annotations. Replay selects an indication or event and restores its context without manually recreating the scan. This supports comparing a change, discussing a case and documenting the reason for a decision.

Reports can be exported as HTML, JSON and CSV with explicit units. Integrity checks and processing provenance help maintain the connection between data and results. The verification documentation records the checks performed and the limits of their conclusions.

Data exchange: the included NDE 4.4 subset

EchoBench implements a documented mapping of the NDE 4.4 format: the public dataset contains one selected raw A-scan, with dimensions 1 x 1 x 512. The complete native session is preserved in the vendor extension, together with the information needed to restore it.

Validation includes the official schemas and exact recovery of samples and session data. Import and export apply to this specific SLX mapping. Integrating other instruments' files, volumetric datasets or DICONDE requires dedicated adapters and interoperability tests.

Trying the Windows preview

Download the portable Windows x64 package from release v0.1.0-preview, extract the complete archive and launch EchoBench.exe, keeping the included folders and resources alongside it. The guided visit introduces the bench; Technical analysis opens signals and maps; Evidence & replay provides sessions and firmware comparison.

The slx-echobench GitHub repository includes the Godot/GDScript interface, API contracts, documentation and examples. The proprietary C++20 engine is distributed as a binary SDK. The project uses the Silicon LogiX Evaluation License 1.0; evaluation purposes and usage conditions are specified in the licence.

From the demo to a custom engineering project

EchoBench provides a concrete starting point for discussing acquisition requirements, error handling, operator interfaces and repeatable tests. Moving to an industrial system starts with real data, the measurement chain and the customer's acceptance criteria.

Commissioned work can include firmware and drivers, FPGA logic and acquisition paths, desktop software, instrument connectivity, hardware-in-the-loop benches and production system integrations. PAUT, TFM and TOFD techniques, qualified acoustic models, robotics and AI analysis require specific development and validation and are extensions to define within a project.

Are you developing an acquisition system or an inspection bench? Tell me about your project: the probe or sensor, available electronics, sampling rate, data format and critical case to reproduce. These are the starting points for a useful, measurable experiment.

Frequently asked questions

Do I need a probe or an FPGA board to try EchoBench?

The included preview runs offline on Windows x64 with a synthetic bench and signals. Firmware and FIFO RTL execute in the virtual environment distributed with the package.

Can the program qualify an inspection on a real component?

The demo explores and verifies the software workflow within the declared model. Qualifying an NDT procedure, characterising real flaw responses and calibrating an instrument require physical experiments and dedicated criteria.

Does the A/B comparison actually execute firmware?

Yes. The firmware execution command runs the ARM ThreadX binaries in Renode on the selected saved point. A separate comparison of the host model processors is also available; the interface distinguishes the two paths.

Can I import any .nde file?

The initial version imports files that follow the SLX single-A-scan NDE 4.4 mapping. Other manufacturers and data layouts require compatibility assessment and an adapter.

Technical references and further reading

The official references and preview documentation below provide more detail about the technologies and project decisions:

AMD - The Programmable Logic Advantage: introduction to FPGAs, programmable logic and reconfigurable architectures, page 5.
Verilator - Overview: from Verilog/SystemVerilog descriptions to compiled executable models.
Eclipse ThreadX RTOS: the official project, kernel services and embedded architecture ports.
Renode - Peripheral modelling guide: virtual peripherals, registers and processor bus accesses.
Renode - Co-simulating with an HDL simulator: further reading on connecting emulated platforms and HDL models.
Godot 4.5 - Introduction to Godot: the 2D/3D engine, applications and supported languages.
NDE 4.4 and the EchoBench NDE mapping: the exchange format and the implemented subset.
EchoBench architecture, local API and verification and limitations: component contracts, responsibilities and experiment conditions.

Originally published on Silicon LogiX.

Robotic digital twin: offline verification with SLX CellProof

Marco — Fri, 16 Oct 2026 08:54:52 +0000

A robotic digital twin becomes useful when it helps explain what changes after a program edit. Moving a pick point, changing a speed or encountering a closed CNC door can affect the whole sequence. With SLX CellProof, Silicon LogiX brings these questions into a desktop application: a demonstration UR5e-CNC workcell, offline programming, a scenario campaign and cycle comparison over time.

The project centres on a digital model of the workcell and its sequences. The 3D scene makes simulator behaviour visible; baselines, events and replay help compare changes. Version 0.5.0 Preview adds persistent projects, recoverable autosaves, a Windows installer and explicit update checks. The software runs locally without a mandatory account.

What is a robotic digital twin used for?

In manufacturing, a digital twin connects a digital representation with models, data and behaviours of the system it describes. The NIST programme on digital twins for advanced manufacturing also addresses synchronization, measurement and model trustworthiness. A 3D shape is therefore a starting point: useful decisions require interpretable state and a declared scope.

CellProof applies these ideas to a nominal demonstration workcell. A robot moves parts between defined stations, interacts with a simulated gripper, digital signals and CNC machine, and follows an editable program. The practical aim is to propose a change, run repeatable checks and find the moment when behaviour diverges. The model is not presented as a calibrated replica of a physical installation.

The application separates offline cycle simulation from read-only RTDE controller monitoring. Receiving telemetry does not automatically calibrate the virtual cell or turn the simulator into a robot controller.

Offline programming for a UR5e-CNC workcell

The Programming workspace combines an editor and the 3D cell. The SLX demonstration language includes joint-space PTP moves, Cartesian LIN segments, gripper commands, IO waits and CNC instructions. Taught points are editable; the pendant provides joint and Cartesian jog and single-instruction stepping. Orbit, zoom, markers and trails put positions in the context of the workcell.

Actual CellProof 0.5.0 screenshot. The editor and 3D view share simulator state; the displayed commands act on the demonstration model.
A first session can start by choosing part A or B, validating the recipe and running the cycle. Save a baseline, change one condition and choose Verify change. SLX is the demonstrator's language: this release does not send that program to a controller or provide a URScript postprocessor for physical execution.

Scenario verification: faults and recovery matter

A successful nominal run still leaves questions open. What happens when feedback is missing? How does an interruption affect the sequence? Which pose and state remain after recovery? CellProof executes eight model scenarios, including fault and recovery cases. Results are computed by the simulation rather than taken from a prewritten report.

A reference baseline makes a change testable. For example, editing a pick point can cause a missed pick: the part is not silently moved to match the new point and force a successful outcome. An obstruction fixture also exercises a geometric case at the CNC entrance. Diagnostics and outcomes help distinguish the expected result from an issue that needs investigation.

These behaviours provide a concrete basis for discussing automation requirements: progression conditions, IO confirmations, interruption handling and recovery criteria. Reported times and outcomes describe the selected model; they do not constitute plant acceptance testing.

Cycle Inspector: synchronized baseline and variant replay

Cycle Inspector records the current and reference simulated cycles separately. Both 3D views can follow the same timeline position; lanes show executed phases, door, grip and IO state. Playback, pause, scrubbing and event navigation let an operator revisit a cycle without manually repeating every step.

Artistic interpretation of cycle comparison: corresponding moments and paths help explain a difference. This is a conceptual illustration, not an application screenshot or a measurement.
The first sampled difference identifies the earliest observed difference in the compared samples. It is a starting point for investigation, rather than an automatic root-cause diagnosis. Notes and bookmarks preserve analysis context. JSON export saves the recording; CSV exposes samples from both runs, joints, TCP, CNC and IO for external analysis.

Cycle Inspector in version 0.5.0. Replay and timelines use nominal simulator recordings; imported local recordings are marked as unverified.
Recordings use 100 ms samples, with a maximum duration of 600 seconds per run. Sampling makes observed states comparable, but does not add continuous geometry checking between samples or measure physical robot timing. This release records the simulator; synchronized hardware trace acquisition would be a separate integration.

The technology stack: Godot 4, GDScript and C++20

Godot Engine provides the desktop interface and 3D visualization. CellProof uses Godot 4.5.2 and GDScript for panels, interaction tools and state presentation. Workcell models are distributed as GLB assets. Programming, verification and cycle inspection share the same graphical environment.

A C++20 core handles nominal kinematics, sequence execution, validation, scenarios and RTDE connectivity. It communicates with the interface through a local JSON message API. This separation supports checking model operations independently of animation. The Windows release includes the compiled core required to run the application.

The public repository contains the Godot interface, documentation, selected assets, publication checks and an approved core binary. Native implementation and private issuing and signing tools are excluded. Original SLX content uses the Silicon LogiX Evaluation License 1.0; Godot and other dependencies retain their respective licences, included with the distribution.

RTDE and URSim: observing controller data

Real-Time Data Exchange, RTDE is the Universal Robots interface for exchanging data with external applications. A configured recipe specifies the transmitted fields. Joint values, timestamps and status need to be interpreted together; the manufacturer's documentation also describes skipped output packages under controller load.

CellProof subscribes to an output-only recipe. Received joint data drives the view, while stale data is reported. The path has been exercised with the official URSim e-Series 5.23.0 virtual controller. URSim is a manufacturer component prepared separately. CellProof sends no URScript, RTDE input recipes or physical motion commands.

Persistent projects, recoverable autosaves and Windows installation

A .cellproof document stores the recipe, taught points, reference baseline, scenario settings, recordings, notes and view configuration. The Project menu provides open, save, recent documents and recovery actions. Recipe-only JSON remains available when exchanging just the program and its configuration.

Recoverable autosaves preserve unfinished work. Project saves use native atomic replacement on Windows, retain a previous complete copy and detect conflicting changes on disk. Actions replacing a project offer Save, Discard or Cancel. Reopening leaves the simulator idle: a document does not autonomously resume a cycle or establish a hardware connection.

The Inno Setup installer works per user and offers shortcuts and optional file association. A portable package is also available. Update checking starts with an explicit operator action, uses the official repository and verifies the installer's SHA-256 checksum. Version 0.5.0 is an unsigned preview: the checksum checks download integrity; it does not authenticate a publisher.

Model boundaries and a path to a physical workcell

CellProof uses nominal kinematics and sampled geometry proxies. It does not provide self-collision, continuous swept-volume checking or complete mesh collision validation. Demonstration metrology is synthetic. Software checks, including automated GitHub validation, cover this scope; they do not qualify installation safety, physical accuracy or hardware cycle times.

A dedicated project can start with workcell CAD, robot calibration, measured base and TCP frames and agreed acceptance criteria. Proposed extensions include controller trace and PLC IO correlation, OPC UA monitoring, trajectory evaluation with MoveIt 2, and virtual commissioning environments using Gazebo and ros2_control. These require implementation and validation for the agreed installation; they are not executable modules included in this preview.

Download SLX CellProof and try offline cycle comparison

The 0.5.0 Preview release provides a Windows x64 installer, portable archive, public source bundle and checksums. Extract the whole portable directory and keep the executable, resources and core binary together. The product interface, Help and documentation are in English.

For a first experiment, validate the nominal recipe, save a baseline, change a point or speed and compare the scenario outcomes. Record the cycle in Cycle Inspector, locate the first differing sample and save a note in the project. This connects programming, outcome and analysis in a short workflow.

See the official repository, user guide and validation scope. To discuss a calibrated model or a dedicated application, contact Silicon LogiX with the robot, machine, available data and verification objective. This demonstrator is part of our work on custom software development for industrial systems.

Frequently asked questions

Can I try CellProof without a physical robot?

Yes. Programming, scenario verification and Cycle Inspector use the included local simulator. URSim is only needed to exercise the separate virtual-controller connection.

Does the preview control a physical UR5e?

No. RTDE monitoring is read only and the SLX language runs in the simulator. Physical motion, calibration and commissioning need a dedicated integration.

Does a passing result guarantee collision-free motion?

No. Outcomes concern the simplified sampled checks implemented by the model. They do not replace workcell validation or independent safety functions.

Can I continue an analysis after closing the application?

Yes. A .cellproof project preserves baselines, recordings, notes and settings. Autosaves and the previous complete save provide recovery options.

Technology references and further reading

Canonical source: Robotic digital twin: offline verification with SLX CellProof.

OPC UA in action: the SLX GridPilot industrial digital twin

Marco — Thu, 15 Oct 2026 14:32:29 +0000

OPC UA becomes easier to understand when a command produces an observable response. A power request, a valve opening, a rotating machine and an alarm connect the protocol to process behavior. With SLX GridPilot, Silicon LogiX presents a desktop application for exploring that path: from the nodes of an OPC UA server to the control of two reversible hydroelectric units and their 3D representation.

The starting point is precise: OPC UA communication and the control runtime are real; the plant is simulated. The computer runs clients, three independent servers and the Eclipse 4diac FORTE runtime. Water, rotating machinery, electrical power and equipment faults belong to the numerical model. This software laboratory serves both people approaching industrial automation and engineers evaluating interfaces, information models and diagnostics without connecting physical equipment.

What is OPC UA, and why does it matter in industrial automation?

OPC Unified Architecture is a platform-independent interoperability architecture. In the client-server model, a server exposes information and services that a client can discover and use: variables, objects, methods and events. For industrial automation, its value includes communicating the meaning of data through types and relationships, beyond a list of numeric values.

A unit's speed, for example, can be presented together with its data type, engineering unit, quality and timestamp. A client can browse the model, read a measurement, call a method and receive notifications. GridPilot applies these operations to a visible scenario: two reversible units, U1 and U2, generating electricity or moving water toward the upper reservoir in pumping mode.

A digital twin demonstrator built around OPC UA

The initial OPC UA Studio workspace displays connected servers, monitored items and notifications received in the current sessions. A live operation map distinguishes the client, servers, FORTE control, simulated equipment and feedback path. These indicators help explain which part of the system is working and where the displayed data comes from.

OPC UA Studio in version 0.4.2. Counters describe actual client connections and notifications; the guided tour verifies server responses.
The three local endpoints represent plant services and the two units: opc.tcp://127.0.0.1:4840, opc.tcp://127.0.0.1:4841 and opc.tcp://127.0.0.1:4842. An external OPC UA client can explore the same model and call its methods. The 3D scene receives state through OPC UA, just like the interface indicators. Selecting U1 or U2 highlights the corresponding unit and lets the operator locate it in the plant view.

From command to feedback: what actually happens

Requesting power does not mean that power has already been delivered. Calling SetPower(1.2) on U1's endpoint requests 1.2 MW of generation. The method's initial response confirms that the request has been queued. LastCommand then reports acceptance or rejection, while power, state and actuator positions show the observed outcome. Hydraulic availability and interlocks can limit the result even when a command is accepted.

The coordinator presents the request to FORTE control logic, which manages sequences and operating limits. The numerical model evolves from the actuator targets; the resulting state is published by the servers and returns to the client through subscriptions. The interface therefore distinguishes request received, command accepted and behavior achieved. The same principle applies to Stop(): confirming a stop requires feedback such as zero speed and closed flow-control devices.

Functional architecture of the demonstrator. OPC UA connects the supervisor to the servers; the coordinator uses local connections to control and model components. Calculated state returns to the servers and client, which also updates the 3D scene.

Exploring OPC UA nodes, types and information models

The integrated browser performs actual Browse and Read operations. Users can search for a node, inspect its type, copy its NodeId and examine quality, timestamps and engineering units. Persistent watchlists follow selected variables, while filters help locate measurements whose quality differs from Good.

A NodeId identifies a node within a namespace. GridPilot's application namespace is urn:siliconlogix:gridpilot:v1. A client must resolve its index on the server instead of assuming that a fixed number always identifies the same namespace. This is a practical detail to understand when moving from an example to integration between different applications.

NodeSet2 XML export, alongside JSON and CSV, documents browsed instances, types and method arguments. It describes the information model: it is neither an executable server backup nor a complete recording of its events.

Subscriptions, quality and timestamps: reading data in context

An OPC UA subscription lets a client receive notifications for configured monitored items. The sampling interval concerns observation of the data; the publishing interval governs notification delivery. A numeric deadband defines a change threshold. The server can revise the requested intervals, and GridPilot exposes those values together with the status of individual monitored items.

Watchlists use a dedicated subscription. Coherent plant state arrives in the Snapshot variable, so indicators and the scene do not have to reconstruct a process snapshot by combining independent reads. SourceTimestamp refers to the sample's UTC publication time; SimTime represents simulated process time. Pausing the simulation therefore does not stop the communication clock.

Quality and freshness have visible consequences: uncertain measurements are identified, and state that no longer receives updates is marked stale. Machine animations do not advance beyond the latest confirmed pose. Motion thus helps users read the available telemetry.

OPC UA faults and alarms: acknowledgement is separate from recovery

The demonstrator supports repeatable actuator, sensor, communication and electrical faults. A simulated speed-sensor error also produces an observable quality change on the OPC UA node. Injecting communication loss for a unit actually shuts down its endpoint, allowing users to examine disconnection, reconnection and the controller's response.

The servers expose standard OPC UA OffNormalAlarmType conditions with severity, message, active state and acknowledgement. An operator can acknowledge a condition and add a comment. Acknowledgement does not remove the fault's cause or automatically release the controller latch: recovery must restore the required conditions. This release uses the experimental Alarms & Conditions support in open62541 1.4.14 and makes no claim of OPC UA conformance certification.

Learning through a guided path and observable checks

The OPC UA Studio tour moves from browsing U1 to requesting power, confirming a stop and injecting a sensor fault, followed by alarm acknowledgement and recovery. Each step advances when the expected feedback is observed. Missing or stale data cannot confirm an outcome.

The plant view complements the experience with overview, cutaway and unit-detail modes. Rotation, flow-control devices, flow indicators and electrical activity make it easier to connect a variable to the relevant machine. Graphics represent received state; the numerical model and control logic determine process evolution.

The Plant view places the 3D model beside operator requests and confirmed values. U1 and U2 labels connect each unit card to its location in the plant.

The technology stack: Rust, Slint, Bevy, open62541 and FORTE

The architecture gives each technology a distinct role. Rust is used for coordination, supervision and the numerical engine. Slint provides the desktop interface; Bevy, together with wgpu, handles the 3D scene and glTF models. Interface and visualization share confirmed process state.

open62541 is the C OPC UA stack used for the servers and client adapter. Eclipse 4diac FORTE is a runtime for function-block applications based on IEC 61499. In GridPilot it executes the application block governing startup, stop, reversal and fault handling. The coordinator maintains a fixed 100 ms step and connects control to the numerical model; supervisor-to-device communication goes through OPC UA.

The hydraulic model is lumped and quasi-steady, with constant efficiencies, actuator limits and water/energy accounting. It is suitable for studying the demonstrator and its interfaces. Designing an actual hydro plant requires further modeling and validation: water hammer, cavitation, electrical-grid transients and qualified electrical protections are examples of phenomena outside this model.

Trends, replay and tests for comparing behavior

The Workbench brings together sequence diagnostics, local numeric history, multivariable charts and CSV export. Commands and alarms can be read alongside measurement trends. Recording, replay, pause and temporal seeking support session review, while test plans define scheduled actions and expected results checked against observed feedback.

For industrial software developers, these functions offer a basis for discussing concrete requirements: how to represent unreliable data, when to declare a command complete, what information to export and what conditions to verify after an interruption. Project checks concern the software and demonstrator model; they do not replace commissioning tests on a real plant.

Download GridPilot and discuss a custom OPC UA project

The SLX GridPilot 0.4.2 release provides a portable Windows x64 package. Download the Windows ZIP, extract the complete folder and launch SLX GridPilot.exe. No compiler, package installation, cloud service or field hardware is required. A Vulkan-capable graphics driver is required. The release also includes SHA-256 checksums for checking the download.

Demonstrator endpoints are limited to the local computer, with anonymous access and SecurityPolicy None. OPC UA provides security mechanisms, but configuring certificates, identities, roles and protected communication for production requires dedicated engineering and verification. The package does not include a preconfigured connection to a physical PLC.

The public repository contains operator documentation, selected screenshots, licensing information and publication checks. The Windows ZIP includes the required runtime data, dependency licenses and corresponding third-party sources. GridPilot's application implementations are proprietary and distributed in compiled form; SDK headers and application sources are excluded from the public distribution. The product license permits study and business evaluation; production integration and redistribution of modifications require written permission. Dependency licenses remain independent.

For an industrial application, a next step may be designing an OPC UA information model, integrating devices and PLCs, developing dedicated supervision, or defining interoperability and recovery tests. These are extensions to agree within a specific project, starting with the actual equipment, security requirements and acceptance criteria. To discuss a project with Silicon LogiX, contact us with the process, the data to expose and the operations the software must support.

SLX OrbitLab: satellite mission software with F Prime and Basilisk

Marco — Wed, 14 Oct 2026 12:37:17 +0000

An Earth observation mission requires coordinated orbital planning, attitude control, energy management and data transfer. SLX OrbitLab integrates these functions in a PC-based software system: a simulated satellite receives a target, plans the pass, acquires an optical product and transfers it during ground-station contact. Commands, telemetry and events track software decisions and the physical model's response.

SLX OrbitLab is the Silicon LogiX platform for satellite mission software development and simulation, autonomous systems and embedded controllers. Version 0.7.0 integrates a native NASA F Prime deployment running on Linux, a proprietary C++ core, Basilisk simulation, a Qt desktop console and Godot 3D inspection. An optional subsystem executes RTEMS firmware on a LEON3 processor emulated in Renode. The platform executes a complete command, physics simulation and telemetry cycle on a PC. Integration tests connect operational decisions, spacecraft dynamics and firmware behavior.

Embedded engineering and mission software integration

Flight software: F Prime components, FPP interfaces, dispatching, telemetry, events and native command sequencing.
Simulation and control: orbital and attitude dynamics, sensor measurements, reaction wheels and energy accounting.
Embedded systems: RTEMS firmware, the LEON3 BSP, timers, periodic tasks, UART and CRC-protected protocols.
Verification: repeatable faults, recording, synchronized replay, strategy comparisons and measured results.
Integration: Qt operation, Godot visualization and a C++ core that can be supplied separately as a binary library.

Mission software architecture: commands, simulation and telemetry

The operational path is explicit: command → mission software → physical simulation → telemetry → console and 3D update. The GUI sends a request; F Prime receives it through its dictionary and dispatcher; the Mission component calls the C++ core to assess conditions and select actions. Basilisk applies actuator commands and power loads, integrates the dynamics and returns new measurements.

At the next step, mission software consumes those measurements, updates its decisions and emits telemetry and events. GUI refreshes do not advance physical time. This boundary makes it possible to repeat an experiment, pause it, advance by individual steps and inspect the same moment through different views.

F Prime executes mission logic; Basilisk returns the physical response. Native packets and simulation snapshots feed recording, the console and 3D views. The optional RTEMS node uses a distinct interface, shown later.

SLX OrbitLab technology architecture

Technology	System responsibility
F Prime 4.3.0 / C++	Commands, components, events, telemetry channels, responses and native sequencing.
Silicon LogiX C++ core	Mission decisions, target management, energy assessment, protection and attitude control.
Basilisk 2.12.0 / C++ and Python	Orbit, attitude, sensors, reaction wheels, solar generation, battery and applied thrust.
Qt 6.12 / QML	Mission console, command and sequence editors, telemetry, recordings and reports.
Godot 4.5 / Blender and GLB assets	Synchronized spacecraft, interior, exploded, orbit and ground station inspection.
RTEMS 5 / Renode 1.16.1	Energy-controller firmware running on an emulated LEON3/SPARC target as an optional subsystem.

F Prime: C++ components, native commands and telemetry

F Prime organizes flight software into components with declared ports and connections. OrbitLab uses this architecture as its command execution path. FPP definitions describe parameters and interfaces, the Ground Data System uses the generated dictionary to encode requests and decode packets, and the native dispatcher delivers each command to its destination component.

Version 0.7.0 exposes 28 dictionary commands and 50 native channels. Selecting a command shows its parameters, examples and operational meaning. Operators can request panel deployment, a relative rotation, Sun or Earth pointing, payload and downlink permissions, a beacon and the orbital maneuvers supported by the model. Diagnostic commands also verify the communication path.

For example, OrbitLab.mission.MANEUVER [3,30] requests a 30-degree relative rotation in mode 3. The dispatcher response confirms acceptance of the parameters; telemetry subsequently shows pointing error, attitude and actuator state. Acceptance, physical effect and operational completion are separate pieces of evidence. An accepted request may remain pending while simulation time is paused or energy, sensors and protection inhibit the action.

For a commissioned project, this executable path supports concrete discussions about interface contracts, parameter bounds, component behavior, failure handling and integration tests.

The F Prime console presents command arguments, operational responses and telemetry from the Linux deployment.

F Prime sequences: planning, validation and execution

OrbitLab integrates native Svc.CmdSequencer execution. Operators prepare plans of 1 to 64 steps with relative delays in simulated seconds and validate them against the session dictionary. F Prime tools compile the binary file; native validation checks its format and CRC before execution.

A plan can run automatically or advance through manual steps. Cancellation, completion verification and responses for each step are preserved. Delays follow simulation time and begin after the previous command's response. Pausing stops this clock as well, keeping sequencing and dynamics consistent.

The eight-step example deploys the panels, suspends the optical instrument, requests Sun pointing, enables the beacon after five seconds, commands a 30-degree rotation after another 45 seconds, disables the beacon after another 60 seconds, and restores the payload and automatic mission. Events and telemetry show the executed list and its consequences for the spacecraft.

Sequences time command requests; they do not automatically wait for attitude convergence. Acquisition conditions remain in the C++ mission state machine. Separating the operational plan from control of physical behavior supports focused testing and a correct interpretation of the results.

The Qt console presents the operational plan and native validation. Step responses and times are preserved; completion of the command list is distinct from physical attitude convergence.

Basilisk: orbital dynamics and attitude control

Basilisk combines C++ numerical modules and Python configuration for space-system simulations. OrbitLab uses this foundation to integrate orbital position and velocity, attitude and angular rate, sensor measurements and reaction-wheel action. Python coordinates the laboratory and adapters; mission decisions execute in the C++ component.

The reference case declares an initial circular orbit at approximately 550 km, a 65 kg rigid body and three reaction wheels. Quantities cross the simulation boundary with explicit units: metres, metres per second, seconds, radians, watts and joules. Attitude and measurements use declared frames, distinguishing the controller's available information from diagnostic simulator truth.

Orbital maneuvers integrate mission commands, operational constraints and propulsion dynamics. An RTN delta-v command is checked against energy, propellant, sensors, alignment and orbital conditions. Basilisk integrates finite thrust applied to the body; reports retain delivered delta-v, remaining propellant and changes to orbital parameters. Adding a terrestrial target during a mission preserves the existing trajectory. The software predicts accessible passes, while a physical burn changes the orbit gradually.

Energy management and activity planning

The battery has a finite capacity of 180 Wh. Solar generation, panel orientation and deployment, eclipse and active loads contribute to the physical balance. The core compares available energy, reserves and activity demand, using a short-horizon energy forecast. The numerical foundation includes Basilisk's storage model and solar-generation model.

When energy is insufficient, acquisition is deferred, loads are reduced and the reason is recorded. The physical model therefore experiences a different consumed power from the load required to capture an image. Battery telemetry reflects an energy balance changed by the software decision. Protection remains active during manual requests.

Two comparable strategies, priority-first and energy-aware, use different planning margins while both protect the minimum reserve. A comparison starts from the same initial conditions, targets, seed, faults and recorded stimuli, with separate F Prime processes and Basilisk simulations. Results include completed or deferred observations, final energy and pointing accuracy during acquisition.

A geometrically useful window is only part of the decision. Software authorizes the activity against energy and sensor state; deferral and its reason become recorded mission evidence.

Earth observation: targets, acquisition and downlink

The operator selects coordinates and priority. Software predicts access windows, commands pointing and requires stability before exposure. The reference configuration requires a measured error below 0.5 degrees, three seconds of stability and a twelve-second exposure. These values are parameters of the simulated mission.

The synthetic optical product uses actual simulated body attitude, camera-ray intersections with the spherical Earth and the geographic texture. Raw data is a 256 × 256 monochrome PGM image. A derived PNG preview relates the target, sensor footprint and cartographic context, making the experiment's content easier to interpret.

Bytes are saved in modeled onboard storage and transferred during a geometric ground-station contact window when energy permits downlink. Storage capacity, the product queue and link availability can change the plan. Delivery is confirmed when the received file passes its SHA-256 integrity check. The link model verifies data handling and mission constraints; it does not calculate an RF link budget or radio modulation.

Qt console and 3D visualization with Godot and Blender

Qt Quick and QML compose the operational console: mission control, F Prime commands, sequence editing, channels, targets and products, orbital passes, tests and recordings. The telemetry model updates values while preserving the operator's browsing position. Parameters and descriptions connect a command to its function, operational response and telemetry. One operator controls a session; viewers receive its state.

Godot 4.5 presents close-up spacecraft, interior, exploded, orbit and ground station views. Component selection connects geometry to subsystems and available commands. Attitude, panel joints, the beacon and antenna follow confirmed backend telemetry.

Blender assets and GLB exports retain original component names, hierarchy and pivots. Earth's illustrative scale and exploded-view offsets belong to presentation and do not enter the dynamics. Blender/glTF axis conversion is explicit and applied once. This integration choice makes 3D a useful inspection tool while keeping it distinct from the physical model.

RTEMS and Renode: embedded firmware on emulated hardware

RTEMS provides the kernel and services for real-time embedded applications. In OrbitLab it executes an independent energy-controller firmware. F Prime remains a Linux process; RTEMS is a separate subsystem. Interfaces between mission software, the energy model and firmware handle power requests, controller responses and load states.

Renode emulates the LEON3/SPARC target, including the peripherals needed for timers and UART. Antmicro's public RTEMS/LEON3 example documents the platform overlap; OrbitLab's integration was verified with its own firmware. Compatibility requires alignment between the ELF, BSP, memory map, clocks and timer, followed by boot and execution tests.

The adapter sends battery energy, capacity, requested power and explicit mission time through sequence-correlated, CRC-protected UART messages. Firmware returns permitted power, flags and the task heartbeat. This permission constrains the loads applied to Basilisk. Tests cover boot, timer interrupts, a periodic task, load reduction at low and critical energy, malformed CRC rejection and recovery after an invalid message.

Emulated time advances in controlled intervals. Missing firmware responses stop the experiment; the laboratory does not silently replace RTEMS with PC logic. Compatibility and integration tests cover this specific combination of firmware, BSP and emulator. Qualification of electronics or a flight processor requires dedicated work.

The physical model retains battery and load dynamics. Emulated firmware authorizes power over a verified protocol, allowing embedded execution and its effect on the mission to be analyzed independently.

Mission scenarios, synchronized replay and results analysis

Operational scenarios and fault management

Scenario	Expected operational outcome
Nominal mission	Target access, stable pointing, acquisition, storage and a delivered file with verified integrity.
Insufficient energy	Deferred activity, a recorded reason, reduced loads and a recorded recharge balance.
Temporary sensor outage	Acquisition held while measurements are invalid, tracked sensor state and renewed condition checks after recovery.

The extended campaign also covers actuator faults, loss of solar generation or ground link, multiple products, full storage and continuous operation. Fault-injection intervals and operator commands are retained as test evidence.

SQLite recording preserves configuration, commands and native packets, events, physical snapshots and products. Replay restores recorded state without redispatching actuator commands. Timeline, telemetry, imagery and 3D follow the same instants. HTML, JSON and CSV reports and SHA-256 manifests support investigation from a shared trace and strategy comparisons with explicit metrics.

The release 0.7.0 acceptance evidence records 26 Linux integration tests, three Windows CTest checks, eight publication-boundary regressions and GUI workflows with native commands, sequences and maneuvers. Operation with a binary SDK, without the proprietary core sources, was verified separately.

The documented SDK case delivers one product with an acquisition pointing RMS of approximately 0.0586 degrees. A maneuver delivers 2 m/s and updates remaining propellant. These are results for the stated configuration and test conditions, rather than an accuracy promise for arbitrary satellites.

Proprietary C++ core, binary APIs and simulation models

The proprietary Silicon LogiX engine exposes a versioned C ABI with fixed-size structures, declared units and an opaque handle. Its interface contains no Qt, Godot, Python or F Prime types. The core can be supplied as a shared library and integrated or updated while preserving the binary contract, independently of presentation and adapters.

The public GitHub repository contains the GUI, integrations, API, example firmware, scenarios, approved assets, documentation and tests. Proprietary core implementation is excluded. Building and running OrbitLab from public source requires the matching evaluation binary SDK; distribution and commercial development follow the project's terms.

The model declares its scope: spherical Earth, simplified reference frames, no J2 perturbation, atmosphere, terrain or thermal environment, an ideal battery, constant dynamic mass and a synthetic optical instrument. It does not represent cell chemistry, analog power electronics or a complete RF link. Repeatability is verified with the pinned Linux environment and the same seed; cross-platform bitwise identity is not promised. The model documentation makes parameters, criteria and simplifications available for review.

Custom engineering for companies and research organizations

OrbitLab's architecture integrates engineering capabilities applicable to mission software, embedded controllers, simulation benches and operational consoles. For companies and research organizations, a project can begin with operational requirements, available measurements, energy constraints, abnormal conditions and system acceptance criteria.

F Prime components: FPP definitions, topologies, commands, telemetry, events, service integration and native tests.
Simulation and autonomy: Basilisk models, C++ control, planning, resource management and fault scenarios.
Embedded firmware: RTOS/BSP integration, protocols, peripherals and emulated-target verification before hardware tests.
Consoles and tools: Qt/QML applications, 3D inspection, evidence acquisition and presentation.
Verification and delivery: repeatable campaigns, agreed metrics, reports, documentation and distributable interfaces.

Explore the OrbitLab repository and technical documentation, or contact Silicon LogiX for a technical presentation, an evaluation SDK or a custom project. The starting point is to define what the system must do, how it should respond at its limits and which tests must document compliance with those requirements.

SLX RadioTwin: industrial radio propagation studies with C++ and Qt

Marco — Tue, 13 Oct 2026 07:20:43 +0000

Silicon LogiX introduces SLX RadioTwin, a desktop demonstrator for studying radio propagation in a three-dimensional industrial plant. The project brings geometry, antenna configuration, obstacles and robot movement into one environment, making it possible to compare how link conditions change. Version 0.2.1 is available on GitHub with a Windows evaluation package.

For a company integrating wireless sensors, gateways or mobile robots, the questions concern what happens along a mission: where does received power fall? Which obstacles does the radio path cross? What difference does a metal door make? RadioTwin makes these questions explorable and documentable, connecting each result to the assumptions that produced it.

Industrial connectivity also depends on geometry

A plant contains surfaces, volumes and passages that affect propagation. Tanks, machine tools, shelving and walls can change the signal path; a door changing state or a moving receiver introduces different conditions even with the same radio parameters. Studying these variations requires a shared reference between object positions, link configuration and numerical results.

The demonstrator uses a scene with 2,584 meshes in its complete representation: a process area with tanks and pumps, CNC machines, a warehouse, a raised control room, robotic arms, an inspection robot, two gateways and a sliding door. The cutaway view allows users to explore the interior, navigate and select components. The RF engine retains the complete enclosure, including walls and the roof, through 373 meshes dedicated to calculations. Opening up the factory view therefore keeps the obstacles in the radio model.

The robot, door and gateways share the scenario state between the visualization and RF geometry. This consistency makes it possible to relate a change in estimated received power to the configuration actually analyzed, while keeping the demonstration animation distinct from experimental measurements.

An explicit RF model with interpretable results

The solver combines free-space path loss with effective losses associated with the obstacles crossed. Intersections are calculated on the triangles of the RF geometry; a BVH, or bounding volume hierarchy, accelerates the search for possible intersections. Antenna positions, frequency, transmit power, gains, receiver sensitivity and material parameters are configurable.

An optional first-order reflection model uses image sources on six enclosure planes. Each path reports power, length and delay. Powers are summed incoherently: this version does not reconstruct the phase interference of a coherent multipath channel. Results distinguish power in dBm, losses and margins in dB, distances in metres and delays in nanoseconds.

Material coefficients are illustrative assumptions, not values calibrated against a real plant. The model supports comparative studies and checks of software behavior; field accuracy requires surveys and calibration. Diffraction, polarization, antenna patterns, protocol traffic and throughput are not simulated in the published version. The RF model documentation describes equations, units and limitations.

From individual links to scenario comparisons

The interface allows users to observe the link as the robot moves, visualize coverage, identify areas with reduced margin and save configurations for comparison. One example is studying an open door against a closed door while keeping the same planned route and radio parameters.

Coverage is sampled on a 49 × 37 grid at receiver height, with points occupied by solids excluded from the count. The mission profile contains 81 samples along the planned 16-metre corridor. The placement search evaluates up to 15 candidates for gateway A, keeps gateway B fixed and compares the worst value of the best link along the route. This is a comparison between defined candidates; mounting feasibility and site performance require separate verification.

The scenario laboratory in the software. The displayed values belong to an example using illustrative coefficients.

Analyses can be exported as PDF, JSON and CSV, retaining the configuration, geometry identity, units and assumptions. For a technical team, this makes it possible to discuss the same configuration, compare alternatives and retrace the reasoning behind a result. Before export, the application requires an updated analysis when the state has changed.

The technologies: C++, Qt Quick and native GPU rendering

RadioTwin demonstrates a software architecture that separates the interface, scenario management and numerical computation. The C++17 core handles asset import, geometry queries, propagation, coverage and candidate evaluation. The desktop presentation uses Qt Quick and QML, while the 3D viewport is implemented in C++ with QQuickRhiItem and Qt RHI, Qt's interface to the graphics backend.

The renderer groups geometry by material and uses GPU buffers. The Windows distribution has been checked with Direct3D 11. GLB/glTF assets retain geometry, materials and hierarchies; coordinate transformations connect the visual representation to the metric system used by the solver. GPU acceleration applies to rendering: RF calculations in this version run on the CPU.

QtConcurrent runs analyses asynchronously on copies of the scenario. The application checks the parameter version before accepting a result, avoiding the presentation of calculations for an earlier configuration as current. The numerical core is distributed as a DLL with a public API and a versioned ABI, while its implementation remains proprietary. This separation provides a starting point for modules and integrations agreed with the customer.

The build uses CMake, Ninja and the Qt 6.12.0 / MinGW GCC 13.1.0 kit. Checks cover reference equations, radio link-budget accounting, reflections, geometry consistency, persistence and scenario comparison. Public-distribution audits also run through GitHub Actions. These checks verify implementation consistency; RF validation at a plant requires independent measured data.

A concrete basis for tailored industrial tools

The value for companies is the opportunity to evaluate a working application and define a specific need: studying a robot route, comparing permitted antenna positions, documenting a scenario or connecting a model to plant data. This provides a basis for a technical discussion about geometry, devices, available measurements and acceptance criteria.

The custom-development section presents eight proposals, explicitly not implemented in the demonstrator. They cover measurement-based calibration and uncertainty quantification; coherent wideband channels with fading and Doppler; MIMO and beam steering; interference and coexistence; robot missions with radio and navigation constraints; network design with redundancy; CAD/BIM, OPC UA or MQTT integration; and research into programmable RIS surfaces and joint communication and sensing.

Each proposal identifies required data, expected outputs and checks to agree on. The application lets users select modules and prepare a local brief containing objectives and constraints. Extensions can then be defined through a feasibility study, a development scope and a validation plan suited to the industrial case.

Evaluate RadioTwin and discuss a project

The SLX RadioTwin repository contains the frontend, public API, binary SDK, assets and examples. Release 0.2.1 includes a Windows x64 package that runs without installing Qt and without radio hardware. A demonstration video with 3D animations and actual software screens is also available.

The license permits study and business evaluation; production integration and distribution of modifications require an agreement with Silicon LogiX. To assess a custom development, contact us with the type of plant, the wireless devices involved, the behavior to analyze and the data already available. These inputs help define the required model, measurement activities and results to verify.

Originally published at Silicon LogiX.

Raspberry Pi 5 AI: quality inspection without the cloud

Marco — Mon, 12 Oct 2026 11:41:55 +0000

A reversed connector, a missing screw, the wrong label: catching a defect before shipping requires a repeatable inspection. Raspberry Pi 5 with local AI is a platform worth evaluating for an initial visual inspection system that processes images close to the machine.

On 5 October 2026, Raspberry Pi published an overview of Sixfab AI HAT+, an accelerator board with a DEEPX NPU. For businesses, the useful question is how to connect image capture, recognition and inspection results in an application that can work without a cloud connection. Read the Raspberry Pi article.

The cover is an AI-generated conceptual illustration. The diagram and example below describe a possible design; they do not depict a system tested by Silicon LogiX.

What Sixfab AI HAT+ and DEEPX add

The 25 TOPS version uses the DEEPX DX-M1M NPU, a processor dedicated to model execution. The Sixfab documentation lists these main specifications:

Sixfab AI HAT+ 25 TOPS: manufacturer specifications checked on 12 October 2026.

Attribute	Specification
AI compute	Up to 25 TOPS at INT8 precision
NPU memory	2 GB dedicated LPDDR4x
Connection	PCIe Gen 3 ×1 to Raspberry Pi 5
Typical power	Approximately 3 W for the NPU alone
Processing	On-device inference, including offline operation after installation

Three watts is not the power consumption of the complete station. Its power budget must include the Raspberry Pi, camera, lighting, storage and interfaces. TOPS, or trillions of operations per second, describes computing capacity; the time to inspect a part must be measured across the complete application.

What can a camera with local AI inspect?

Start with a defect that is visible, clearly defined and distinguishable at the available resolution. Three examples illustrate the kinds of projects to consider:

Assembly: check whether a connector or component is present and correctly oriented, with a controlled capture position.
Packaging: identify a missing accessory or an incorrect product arrangement before closing the package.
Surface finish: evaluate detection of scratches or surface anomalies after checking optics, contrast and lighting.

A camera cannot see beneath an opaque component or replace an electrical measurement. On an electronic assembly, it can complement functional testing: images check assembly, while measurements check behavior. Reading a code or checking a stable geometry may also be a good candidate for traditional computer vision algorithms.

From the part to the result: an inspection example

Imagine a station that checks a connector on a small electronic module. An operator places the part in a fixture; a signal triggers capture; the software analyzes the image and displays the result. Communication with the machine uses an interface designed for its controller.

Part + controlled lighting
         |
         v
Raspberry Pi 5: capture and preparation
         |
         v
DEEPX NPU: model execution
         |
         v
Inspection software: rules and review
         |
         v
Result: operator, controller and records

An original diagram of a possible station. Application software connects the model output to the product acceptance rules.

For this application, we would design three outcomes: accepted, defect detected and review required. A blurred image, a misplaced part or an insufficient score should trigger recapture or operator review. The application must handle uncertainty before commanding a rejection.

Each inspection should record the part identifier, timestamp, model version and outcome. Which images to retain, and for how long, depends on the process. These records make it possible to investigate inspection conditions and compare two software versions against the same cases.

Do you actually need a Raspberry Pi 5 NPU?

The decision depends on the real workload. Before buying an accelerator, measure a CPU implementation with the intended model. An NPU becomes interesting when inference time, image volume or application load requires more headroom. Our guide to NPUs in embedded systems explains the accelerator’s role.

Consider an illustrative timing budget: at 60 parts per minute, a part arrives every 1,000 milliseconds. A proposed budget could allocate 100 ms to capture, 150 ms to processing and 100 ms to decision and communication, leaving 650 ms of headroom. These are design examples, not measured board performance. The available capture window also matters: the part may spend much less than one second in front of the camera.

Testing must include the slowest cycles while the system saves images, updates the interface and communicates with the machine. A favorable average can hide occasional delays, image queues or missed acquisitions.

How an AI model reaches the board

In the workflow documented by Sixfab, a supported model is exported to ONNX, compiled with DX-COM on an Ubuntu x86_64 machine and deployed as a .dxnn file. The Raspberry Pi runtime executes it through C++ or Python APIs. Training and compilation are separate from on-device inference.

A product-specific defect requires representative images and consistent annotations. When photographing the same parts repeatedly, avoid placing near-identical images in both training and test sets. Splitting samples by physical part or production lot makes evaluation closer to real use.

The INT8 conversion requires checking the deployed model: changes in its results must be measured on your own defects. For repeatable development cases, SLX SynthForge demonstrates a workflow with synthetic scenes and data. A production line still requires real images and validated capture conditions.

How much does a Raspberry Pi quality inspection system cost?

The Sixfab product page lists the 25 TOPS AI HAT+ at US$90 as of the consultation date. That is the add-on board price; the Raspberry Pi and complete station must be budgeted separately. Check the final price, taxes and shipping with the supplier for your destination market.

The project budget should include:

Image capture: camera, lens, lighting, mounts and the part fixture.
Electronics: computer, power supply, cooling, enclosure and controller connection.
Data and model: sample collection, annotation, training and evaluation.
Software: operator interface, result handling, records and business-system integration.
Commissioning: testing on real lots, acceptance thresholds and maintenance.

To estimate the station’s value, compare total cost with the existing process: inspection time, rework, rejected parts and escaped defects. A prototype helps collect the evidence for that assessment before extending the system to production.

Five checks before putting AI on the production line

Missed defects: measure how many defective parts are accepted and which defects remain difficult.
False rejects: check how many conforming parts are rejected or require manual review.
Real conditions: test different lots, position variations, reflections and lighting changes.
Continuity: check restarts, camera disconnection, exhausted storage and communication loss.
Updates: retain the approved model and software, a fixed test set and a procedure to restore the previous version.

Define these criteria before testing. If a model is selected after repeated trials on the same samples, use another independent set to verify the result. For multi-camera lines, our article on industrial vision over Ethernet also covers bandwidth and capture architecture.

Frequently asked questions about Raspberry Pi AI inspection

Can inspection work without Internet access?

Inference runs locally after installation. Offline station operation also depends on application choices: models, licenses, authentication and result recording must be available at the deployment location.

Will a ready-made model recognize my product’s defects?

A pretrained example helps verify that the system processes images. For a specific defect, evaluate behavior on your own product samples and prepare a dedicated model if necessary.

Can the board also accelerate language models?

The consulted sources disagree: the Raspberry Pi post also describes language models, while Sixfab lists vision as the current scope. This article considers visual inspection. A language-model project requires support confirmation for the chosen hardware, model and runtime.

From a specific defect to a feasibility study

Silicon LogiX can support a project by connecting AI and machine learning, embedded Linux and custom software. The first step is defining what to observe, the required timing and how to use the result in the business process.

Want to assess whether AI can catch a defect in your product? Describe the inspection you want to automate, your available samples and the line cadence. These details help establish a useful feasibility study.

Technical sources consulted on 12 October 2026. Specifications and pricing are manufacturer statements; the timing example and evaluation criteria are Silicon LogiX design contributions.

Originally published on Silicon LogiX.

SLX ResilienceLab: simulated faults, measurable control responses

Marco — Sat, 10 Oct 2026 11:31:04 +0000

A sensor keeps sending a plausible value while the actuator moves away from it. The primary controller stops responding. Two measurements disappear while the system is approaching its requested position. Control software must handle these conditions, yet ordinary bench tests can make them difficult to reproduce.

SLX ResilienceLab is Silicon LogiX's new desktop demonstrator for exploring these cases in an entirely software-based test bench. A virtual motorized valve, three position sensors and two C++ controllers let you observe the response, inject faults and retain the results. The project demonstrates how a dedicated test environment can be built around a product's control software.

For teams developing boards, firmware or machinery, the practical value is repeatability: recreate a critical condition, compare two control versions and discuss the response using recorded measurements, timings and events. Contact me to discuss a test bench for your product.

A virtual valve with decisions computed by the software

The operator requests an opening, such as 80%, and follows the valve's movement in normal and cutaway 3D views. The interface keeps requested opening, actual model position, three sensor readings and the control measurement separate. This makes it possible to see when a reading no longer represents the movement.

The primary and backup controllers execute real C++ code. They receive measurements and messages through a virtual transport and calculate the motor command. They cannot directly inspect the plant's actual position or the operator's fault settings: they must respond using received information. Heartbeats, commands and measurements travel through the transport, where delays and losses can be introduced.

An actual laboratory screenshot during the stuck-S1 scenario. Model position and the measurement used by control remain visible as separate values.

Sensor redundancy compares readings using configurable disagreement thresholds, confirmation times and freshness limits. With two trustworthy measurements, it can exclude a disagreeing sensor; when information is insufficient, it requests a stop. Arbitration authorizes only one controller to command the motor at a time, including during transfer to backup.

Three tests with observable responses

The demonstrator includes three ready-to-run scenarios. The following chart uses traces produced by executing version 0.4.0, with an 80% requested opening, 12 simulated seconds, a 20 ms step and seed 2407. It represents software model results under these stated conditions.

Green: actual virtual plant position. Grey dashed line: requested opening. In the first chart, red: the frozen S1 reading. Times are simulated, not measurements from physical hardware.

Stuck sensor. S1 freezes at 1.60 s. The first isolation event appears at 2.12 s, after 0.52 s; the primary isolates S1 at 2.14 s. Control continues with S2 and S3 and finishes with approximately 0.14 percentage points of position error.
Primary controller loss. The controller stops at 2.00 s. The watchdog stops the motor at 2.24 s and arbitration authorizes backup at 2.58 s: takeover occurs after 0.58 s. The valve resumes movement and finishes with approximately 0.16 percentage points of position error.
Measurement loss. S1 and S2 disconnect at 2.00 s. Their readings expire at 2.40 s and the motor stop is applied at 2.42 s. Final position is 51.48%: the expected outcome is to stop because sufficient information is unavailable.

The report retains position errors, detections, transfers to backup and stops. HTML, JSON and CSV exports make the evidence accessible and usable in other tools. Configuration, the fault timeline and seed let you replay a scenario and compare two control versions under the same simulated conditions.

Why this approach helps embedded development

The principle is software-in-the-loop: execute compiled code on a computer and subject it to repeatable test inputs. MathWorks' SIL and PIL documentation describes how these environments help verify code behaviour during development. ResilienceLab applies this principle using its own C++ and Qt Quick architecture.

Fault injection makes the condition under test explicit. Alongside the ready-to-run scenarios, the laboratory supports progressive sensor drift, disconnections, intermittent communication and actuator jamming. In a physical bench, electrical faults require dedicated interfaces: NI's explanation of fault insertion units illustrates that testing layer. In this demonstrator, faults affect the model and its messages.

For a development project, the benefit is defining verification criteria early: how many measurements are needed to continue, how quickly a loss should be detected, which controller may issue commands and which events must be retained. The same test can then become a regression check when firmware changes.

From PC control to a board connection

The laboratory also supports live operation: change the requested opening and freeze, disconnect or restore sensors while the valve is moving. Actions are recorded so the test can be reconstructed. 1× mode follows the PC clock; a desktop operating system does not guarantee strict execution deadlines.

Message exchange closes the control loop. Actual position remains a reference for observation and reporting; the controllers operate on received measurements.

To integrate customer code, a DLL interface with a C API can replace the motor-command calculation on the PC. The bench retains measurement handling, heartbeats and arbitration. A local JSON-message API provides measurements and diagnostics, changes the setpoint and requests faults; local TCP and USB/serial connections are available in the software. Integrating a specific board requires implementing and verifying the corresponding firmware protocol.

A further step is hardware-in-the-loop, connecting a physical controller to a simulated environment. As NI's HIL overview explains, appropriate timing and input/output interfaces are part of that architecture. Board firmware driving the virtual plant is an integration to be developed; ResilienceLab currently provides the software demonstrator and its connection points.

Three sensors frozen at the same value can still agree. Majority voting alone does not establish that the valve is moving: in the laboratory, a movement request also enables measured-progress monitoring. This illustrates why a bench must be designed around the product's faults and requirements. SLX ResilienceLab is a software demonstrator with no safety certification; it does not validate a physical valve or a customer's firmware.

A test bench designed for your product

Silicon LogiX can build a dedicated environment for a board or control system: a plant model, an adapter for the product's interfaces, fault scenarios, acceptance criteria and reports. The starting point can be one concrete function, such as verifying the response to a frozen sensor or interrupted communication.

Tell me about your product, available interfaces and the behaviour you need to verify. If you already have a board, include its protocol, signals and timing requirements. We can define a representative first test and the integration path. Let's discuss your test bench.

Explore the project through the portable Windows v0.4.0 release and the GitHub documentation. The proprietary core is distributed as compiled libraries under the Silicon LogiX evaluation licence; the interface and integration examples are separate.

Originally published on Silicon LogiX.

SLX SynthForge on GitHub: AI for industrial vision

Marco — Thu, 08 Oct 2026 18:01:47 +0000

SLX SynthForge is available on GitHub, bringing together computer vision for electronic board inspection, 3D scenes and synthetic data. The Silicon LogiX desktop application lets operators edit a virtual board, capture its image and analyse defects with an AI model that runs locally.

The application uses C++17, Qt Quick and QML. The proprietary Silicon LogiX SynthForge Core engine handles rendering, visual analysis and inference, while Python and NumPy train the classifiers. The project documents the workflow from preparing examples to comparing model versions and preserving inspection evidence.

From a 3D board to defect detection

The reference scene is PowerBoard, a demonstration board with 46 editable components. Operators can remove a component, change its position or rotate it before starting an inspection. The board model distinguishes nominal appearance, missing components and changes in position or appearance.

Each result connects the CAD reference to the captured image detail, the score and the model identity. Outcomes are labelled PASS, DEFECT and REVIEW: an accepted component, a detected defect or a case requiring review. Insufficient visibility or captures outside the expected profile require review, as described in the inspection workflow.

Virtual board inspection: defects in C2 and U4 are associated with the captured image and their CAD references.

The vision engine: Silicon LogiX SynthForge Core

At the centre of the application is a C++ engine distributed as a binary SDK in the SiliconLogiX.SynthForge.Core.dll library. Public APIs expose rendering, dataset generation and inspection functions. The Engine module produces the scene image and applies the numerical model to the capture. The SDK documentation describes the separation between the interface and the engine.

Board recognition uses a 640 × 480 pixel RGB image and a defined inspection camera. The engine analyses the captured pixels; commands used to introduce defects remain preparation and traceability data. Model compatibility, asset identity and capture conditions are checked before inference.

CAD scene
  ↓ RGB capture
  ↓ Visual features
  ↓ Linear softmax classifier
  ↓ PASS / DEFECT / REVIEW and report

The C++ engine connects the virtual scene to image analysis and the inspection outcome.

Machine learning: visual features and softmax classification

The AI technology is a multiclass linear classifier with a softmax function. Numerical image characteristics, called features, are normalised and combined with weights learned during training. Softmax produces class scores, which are used alongside acceptance thresholds and capture checks.

The editable board inspector works with 16 visual features per example and three classes: nominal, missing, and changed position or appearance. The inspector training pipeline preserves normalisation parameters, weights and the model identifier.

The dedicated C1 and U4 component laboratory uses 24 × 24 pixel RGB crops aligned to the component regions. Its model distinguishes five scenarios: nominal board, missing component, misalignment, reversed polarity and solder bridge. This is a separate pipeline with its own visual softmax classifier. Scores describe the model response and need to be assessed in the context of the experiment.

Python and NumPy for model training

Training uses NumPy for numerical computation and the Adam optimiser to update weights. The loss function is cross entropy, which measures how far classifications differ from example labels. The model is selected using validation loss.

Training, validation and testing have distinct roles. Normalisation is fitted on training data; a separate test set evaluates the model after selection. Parameters are exported as versioned JSON files and loaded by the C++ engine for inference. Inspection with the included models works without installing Python; a Python environment is needed to train new models.

Synthetic data and capture robustness

Dataset forge generates examples from the 3D scene and associates them with simulated defect labels. This makes experiments repeatable, organises cases and diversifies training examples. Capture groups are separated between training, validation and testing to reduce data leakage.

Robustness lab varies lighting, reflections, blur and camera tilt. Its result grid shows where the model maintains acceptable decisions and where review or a new capture is needed. The evaluation workflow connects image quality to classifier behaviour.

Qt Quick and C++ for the desktop application

Qt Quick, QML and Qt Quick Controls provide the operator interface: board editing, capture controls, inspection results and AI laboratories. OpenGL handles the interactive 3D preview, with a software mode available for workstations that need it.

C++ services coordinate processing outside the interface flow, keeping presentation separate from rendering and generation tasks. CMake and CTest organise builds and automated checks. The documented architecture distinguishes presentation, the vision engine and training tools.

Model comparison and result traceability

Assembly AI lab collects development cases, prepares new examples and compares the initial model with a candidate. An independent benchmark is frozen before collection: both versions are evaluated on the same data with the same threshold. New examples feed training and validation.

The comparison considers missed defects, false alarms, REVIEW cases and the proportion of accepted decisions. Candidate activation is explicit. Experiments and reports preserve images, CAD references, edits and model identity; HTML, CSV and JSON formats make outcomes accessible. The published validation documents results and the conditions of synthetic experiments.

How to try SLX SynthForge

The v0.4.1 release includes a portable Windows package. The GitHub repository contains application sources, screenshots, documentation and examples. The proprietary engine is supplied as a binary SDK under the Silicon LogiX evaluation licence.

SynthForge is an industrial vision demonstration environment based on synthetic data. Applying the workflow to a production line requires validation with real images, optics, lighting and defects representative of the product.

Industrial vision and custom software

For businesses developing inspection tools or integrating visual analysis and reporting, Silicon LogiX offers custom software development and AI and machine learning services. SynthForge shows how a desktop interface, native engine, training data and verifiable results can work together.

Contact Silicon LogiX about an industrial vision project: describe the process, available data and required functions to define requirements and feasibility experiments.

Topics and technologies

Originally published on Silicon LogiX.