What's inside, besides the hardware
A board with factory Linux is not yet a device
The same system components on every edge computer in the catalog: a ready-to-run Linux system image with drivers and runtimes, OTA updates with A/B rollback, signed images. Everything runs inside your network perimeter, we have no cloud of our own, your model is deployed as a container.
01
Ready-to-run Linux system image
Kernel with patches, NPU and camera drivers, runtimes at pinned versions, Docker, OTA updates with rollback. One image per SKU, a changelog and component versions with every release. Included in the device price.
| Base | Debian 12 with the SoC vendor's kernel and our patches (Rockchip); JetPack 6.2 / L4T 36.4 (Jetson) |
|---|---|
| Containers | Docker / containerd; your model is a container with an input/output description; cgroups limits |
| Runtimes | RKNN-Toolkit2 2.3.x and ONNX Runtime on RK3588; CUDA 12.6 / TensorRT 10 / DeepStream 7 on Jetson — versions are pinned and change only with a release |
| Cameras | UVC drivers, V4L2 / libcamera and Argus for MIPI CSI, an ONVIF / RTSP client for IP cameras; exposure profiles per scene |
| Boot | A/B partitions: after a failed update the device rolls back to the previous image; secure boot and root filesystem integrity verification — on request, per project |
| Updates | the image and the model container are updated over the air with rollback on failure (A/B, a Mender / RAUC-class mechanism); images are signed; delivered from your network, no cloud of ours; integration with your fleet-management (device management) platform — on request |
| Data | our components store no video and no frames; data-at-rest (storage) encryption — on request, per project (depends on the SoC and the storage medium) |
| Reliability | hardware watchdog, RTC, health log, autostart after a power failure |
| Network | outbound connections only, to the addresses you set: your update server, your NTP, your services; SSH — with your keys; no keys of ours in the image |
02
What is disabled, where the device connects — and where it doesn't
The public part of the vendor security questionnaire. The full questionnaire — on request under NDA; for IP cameras — a check report for every unit at incoming inspection.
| Disabled | Bluetooth / Wi-Fi (physically absent on devices without radio), Avahi / mDNS, UPnP, telnet, default passwords, UART debug ports disabled on production units |
|---|---|
| Where it connects | only to the addresses in your config: your update server, your NTP, the services to which your container sends its output; you see and edit the list yourself |
| Where it doesn't | the internet, us, the SoC vendor; no telemetry to us or to the SoC vendor; we have no cloud and no message broker of our own |
| Updates | signed images, delivered from your network, automatic rollback on failure |
| Audit | list of open ports and component versions — in the vendor security questionnaire on request; for IP cameras — a check report for every unit at incoming inspection |
03
Who fixes what
We are responsible for the kernel, drivers, runtimes and updates across the whole installed base — and we state where our area ends. The default image is ready-to-run; installing the components on your base OS or getting the sources is possible under a contract (see FAQ). The only timelines on this website are those already promised by the RMA procedure; the rest — in the contract.
| Our components: our kernel patches, runtime integration, image build, OTA updates | we fix them ourselves: response to a critical defect — 4 business hours; a workaround or rollback to the previous image — over the network; the fix — in the next patch release (cadence and timelines — in the contract) |
|---|---|
| Closed parts of the SoC: NPU driver blobs, the RKNN / TensorRT runtime, camera firmware | we do not patch closed binaries — we reproduce the issue, provide a workaround, pin the version, roll back, escalate to the SoC manufacturer; the fix arrives on the manufacturer's timeline |
| Your container, your model, your base OS outside our components, your security and monitoring agents | your area; model conversion for the NPU and adaptation of components — custom engineering on request |
| Vulnerabilities | critical vulnerabilities in our components are closed with a patch release; a changelog and component versions — with every release |
| Channels and scope | a request by e-mail with the serial number; a dedicated chat and engineer for a large customer. Free during the warranty; afterwards — under a support contract; extended support — by contract |
04
Board measurements and tested tools
Throughput, model quality and execution conditions. Single-context, parallel and live trials are separate, with duration stated for every result.
05
Custom engineering on request
One-off engineering work as a separate line in the quotation, paid before the work starts. Estimates take 2 business days and are free.
- Conversion of your model for the NPU (ONNX → RKNN INT8) with accuracy measured before and after — you receive a measured accuracy figure, not just the word "optimized"
- A system image on your base OS (Ubuntu LTS; Astra SE / RED OS / ALT — verified on samples) or on your Jetson carrier board
- Secure boot, integrity verification and data-at-rest encryption per your project requirements
- Integration of updates into your fleet-management (device management) platform (Mender / RAUC / your own) or a connector from the model container to your message bus (MQTT, Kafka, HTTP) following your schema
- Enclosure, mounting, cable harness and power supply for your site or machinery
- Industrial builds: −40 °C, CAN / RS-485, PoE output, GMSL2 — made to order per the catalog page