Release Notes — Coldwave Yukiblock CAN

First production release of the Coldwave Yukiblock CAN firmware — an LTE-M / NB-IoT CANopen field-bus gateway with on-device PLC-style scripting, secure boot and signed over-the-air updates.

Manufacturer: ImagineOn GmbH, Köln · Document generated from the curated public release-notes source.

1.0.02026

First production release of the Coldwave Yukiblock CAN gateway firmware and the baseline of the 1.x line, developed under an IEC 62443-4-1-tailored secure development lifecycle.

Added

CANopen field-bus gateway — bridges a CANopen bus (SDO / PDO / NMT / EMCY / Heartbeat services) to the Coldwave cloud, applying a backend-curated mapping table between CANopen objects and Coldwave properties with content-match filtering. Property writes are routed back to the corresponding objects on the bus.
Classic CAN 2.0 field-bus interface through an external CAN controller, with a power-on loopback self-test at boot.
On-device PLC-style scripting via the Coldwave Script VM sandbox, running in a constrained profile. Scripts are delivered over the TLS-protected property channel.
LTE-M / NB-IoT connectivity through the Coldwave modem stack.
Battery-backed real-time clock with automatic time-zone resolution from the mobile network, so timestamps and TLS certificate validation stay correct across power cycles.
Monthly data-budget guard with a configurable cap and automatic reset on the month boundary, with the remaining budget retained across power cycles.
Emergency property sync on power loss — a supercapacitor-backed shutdown hook flushes queued property updates to the backend and parks the CAN interface before brown-out.
Secure boot and signed OTA updates — firmware images are ECDSA-P256-signed and verified by the bootloader before they are booted.

Fixed

Closed a memory leak on the malformed-frame error paths of the CANopen mapping deserializer, surfaced by continuous fuzzing under a memory sanitizer.
Hardened the mapping content-match path against out-of-bounds reads when parsing malformed backend mapping data.

Security

The CANopen SDO client-parameter object (0x1280) is now read-only over the field bus, removing an unauthenticated remote-reconfiguration path.
Communication-parameter objects held in read-only storage are now rejected by the SDO server before any write is attempted, closing a field-bus-reachable remote-reset (denial-of-service) path found through continuous fuzzing.
This is the initial security-conformant baseline. Additional security-relevant fixes are listed under Fixed; there is no predecessor release from which issues carry over.

Quality and security assurance

The 1.0.0 image ships from a host quality pipeline enforced in CI: static analysis on security and quality rule-sets with no outstanding critical or high-severity findings, software-composition analysis with no known critical or high-severity vulnerabilities in third-party components, unit and end-to-end tests, and continuous fuzzing of the CANopen mapping and SDO parsers.

Known limitations

External RED / EN 18031-1 certification by an accredited body has not been performed for the 1.0.0 baseline; conformity is established on a self-assessment basis.
The EU Cyber Resilience Act reporting workflow is prepared. ENISA reporting obligations apply from 2026-09-11, with the full regulation applicable from 2027-12-11.