Cart
CloseNo products in the shopping cart.
No products in the shopping cart.
Managing a Board Support Package (BSP) in an industrial embedded system has never been a trivial task. A BSP is the foundational software layer that ties the operating system to the specific hardware: it includes kernel configuration, device drivers, bootloader, root filesystem and all the low-level glue that makes a board actually run. Keeping it up to date, secure and consistent across a fleet of deployed devices is one of the most demanding challenges in embedded engineering.
ToloMEO, the fleet management platform from DAVE Embedded Systems, addresses this challenge head-on through the Embedded Manager module — the operational core of the entire stack. The architecture flowchart below captures in a single diagram how the BSP lifecycle is orchestrated: the Production Management System feeds NPI and provisioning data downward, the Embedded Manager coordinates the build and distribution pipeline at the center, the Board Farm validates every release on real hardware to the left, Cyber Security monitors and triages vulnerabilities to the right, and the IoT module carries validated firmware out to the field at the bottom.
This article follows that flow, step by step.
The first arrow in the diagram points downward from the Production Management System to the Embedded Manager, labeled NPI / Provisioning. This is where a new product introduction or a device configuration change originates.
In practice, NPI covers everything that needs to happen before a device leaves the factory: hardware variant selection, initial software stack assignment, certificate injection, secure boot key provisioning and factory-level configuration. The Production Management System holds the master record of what each device is, which BSP version it should carry, and what credentials have been assigned to it. The Embedded Manager consumes this information to ensure that every unit starts its life in a known, consistent, compliant state.
This upstream integration is what distinguishes a managed BSP lifecycle from ad-hoc firmware flashing: instead of configuring each device manually, the process is governed by structured data flowing from a single source of truth.
The downward arrow from Embedded Manager to Production Management System carries the labels Compile / Build / Create Artifacts / Report — and this is where most of the engineering work happens.
The Embedded Manager provides a professional multi-stage build infrastructure built around dedicated virtual machines: a Build VM handles compilation and image assembly, a Signing VM manages cryptographic operations, and a set of Git repositories (DAVE's own, the customer's and public upstream sources) are coordinated to produce a coherent release. Smart caching minimizes build times across the typically six BSP releases per year that DAVE maintains for its hardware platforms.
Each build run produces not just a firmware image but a full set of artifacts: the signed binary, the Software Bill of Materials (SBOM), and the associated VEX (Vulnerability Exploitability eXchange) document that records which known vulnerabilities affect this release and whether they are exploitable on the target platform. These artifacts are stored, versioned and made available for downstream validation.
The dual-ownership model supported by the Embedded Manager is worth noting here. DAVE maintains the core BSP — kernel, drivers, OS hardening aligned with IEC 62443 — while customers extend it with their own application layers and features. The platform coordinates both contributions, ensuring that customer customizations survive BSP updates cleanly and that security hardening is never accidentally undone.
Before any firmware reaches the field, it passes through the Board Farm — the bidirectional connection to the left of the Embedded Manager in the diagram, with Report flowing right and Test flowing left.
The Board Farm is a Hardware-in-the-Loop testing infrastructure physically hosted at DAVE's premises. Every new BSP release is automatically loaded onto real target hardware, subjected to controlled power cycling, and run through a full suite of functional tests that simulate real-world operating conditions. This is not emulation or simulation — it is the actual hardware that customers deploy, exercised with the actual firmware that will be distributed.
The test results flow back to the Embedded Manager as a structured report. Only BSP releases that pass the full validation suite are promoted to the distribution pipeline. This gate is what gives the phrase "production ready" on the downward arrow toward IoT its concrete meaning: a firmware image earns that label by surviving real hardware testing, not by passing a checklist.
The boundary scan and functional test capabilities of the Board Farm also serve a secondary purpose: they catch hardware-software integration regressions early, before they propagate to deployed devices where a recovery requires a field intervention.
The right side of the diagram shows the bidirectional link between the Embedded Manager and the Cyber Security module: SW/HW BOM flows outward, Report flows back, and the caption below lists Analyze, Triage, Report.
This flow represents the continuous vulnerability management process. The SBOM generated at build time is passed to the Cyber Security module, which cross-references it against CVE databases and monitors for newly disclosed vulnerabilities on an ongoing basis. When a relevant CVE is identified, the module initiates a triage workflow: the vulnerability is assessed for exploitability on the specific hardware and software configuration, a risk level is assigned, and the Embedded Manager receives a report that may trigger a change request for the next BSP release.
This closed loop is what transforms security from a one-time activity at project launch into a continuous operational capability. In regulated markets — healthcare, railways, industrial automation — the ability to demonstrate that vulnerabilities are being actively monitored, triaged and remediated is increasingly a compliance requirement under frameworks like NIS2, the EU Cyber Resilience Act, and IEC 62443. The Embedded Manager generates compliance-ready reports to support exactly these obligations.
The final arrow in the flowchart points downward from the Embedded Manager to ToloMEO IoT, labeled Production ready, with the caption Local update / OTA update / Log.
Once a BSP release has cleared the build pipeline, passed Board Farm testing and satisfied the security triage, it is handed off to the OTA distribution system. The Embedded Manager coordinates with the IoT module to manage the rollout: update packages are signed and verified before transmission, delta updates minimize bandwidth consumption, phased rollouts limit blast radius if an unexpected issue emerges in the field, and automatic rollback ensures that a failed update does not leave a device in an unbootable state.
The local update path covers devices that are not permanently connected — they can receive firmware through a local interface when they check in — while the OTA path handles the broader fleet. Both paths feed back to the Embedded Manager through the log, maintaining a complete audit trail of which device is running which firmware version at any given time.
What the flowchart represents, and what ToloMEO delivers, is a BSP management process that is continuous, automated and observable end to end. Every release follows the same path: it is built from governed sources, signed, tested on real hardware, security-checked against current CVE intelligence, and distributed with rollback safety to devices that are individually tracked.
For engineering teams that have historically managed BSP updates through manual processes — a script here, a USB stick there, a spreadsheet tracking what is running where — the contrast is significant. The Embedded Manager removes the single-point-of-failure of tribal knowledge and replaces it with a repeatable, auditable pipeline that scales from a handful of prototypes to thousands of deployed units without changing the process.
For product managers and compliance officers, the outcome is a system whose security posture can be demonstrated at any point in time: which version is running on which device, what vulnerabilities are known, what the remediation timeline is, and what the test evidence shows.
BSP management is one of those problems that looks manageable at small scale and becomes genuinely hard as a product matures and its fleet grows. ToloMEO Embedded Manager was designed to absorb that complexity: it connects provisioning, build automation, hardware testing, vulnerability management and OTA distribution into a single governed workflow, keeping industrial embedded devices secure, up to date and traceable throughout their operational life.
Fields (*) are required.
Welcome to the DAVE Embedded Systems' Documentation system. Please fill in with required information and you will get your document! Thank you!.
We use cookies to personalize content, to get traffic statistics and to improve your experience on our website.
Please read our Cookie Policy for a more detailed description and click on the "Manage preferences" button to customize how the site uses cookies for you. By clicking on "Accept all cookies" you give your consent for the use of each type of cookie.
These cookies are necessary for the website to function and cannot be switched off in our systems.
You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site.
All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
Select all Deselect all