Automotive BLE development services is a phrase that covers two very different things. One is a supplier who sends you engineers and bills by the hour, where the deliverable is attendance. The other is a partner who takes a defined scope and hands back working firmware, a test rig, a certification pack and an update pipeline, where the deliverable is a shipping product.
The gap between those two matters more in vehicles than in consumer electronics, because a Bluetooth stack in a car now has to survive a type approval process that did not exist a few years ago. Whoever writes your firmware is writing evidence for a regulatory audit, whether or not their statement of work says so.
This article sets out the six things a competent partner delivers, what each one looks like as a concrete artefact rather than a promise, and the questions that separate a delivery partner from a body shop. It is written to be used while evaluating anyone, including us.
What “development services” should mean
The useful test is what exists at the end that did not exist at the start, and whether it works without the supplier in the room.
A staff augmentation engagement leaves you with people who leave. A delivery engagement leaves you with artefacts: a stack running on your silicon, a hardware in the loop rig your own team can run, a qualification submission with your company on it, an update pipeline that ships firmware to vehicles in the field, and documentation good enough that a new engineer can pick it up.
Both models are legitimate. Semiconductor vendors ramping a new part often want an embedded team for years. Hardware OEMs shipping one product usually want a scoped delivery. The failure mode is buying one and expecting the other, which is why the first question to ask any automotive BLE development services supplier is which of the two they are proposing, and what specifically you hold at the end.
Engagement shapes worth recognising, using needCode’s own as an example of how this is usually structured:
| Model | Typical duration | What you hold at the end | Fits |
|---|---|---|---|
| Audit and roadmap | 2 to 4 weeks | Audit report, remediation roadmap, leadership presentation | An existing stack or SDK that is underperforming and you need to know why |
| Greenfield design | 8 to 16 weeks | Architecture specification and reference implementation | New silicon or a new product line with nothing to build on |
| Modernisation | 12 to 24 weeks | Migration plan, updated CI/CD infrastructure, compliance ready stack | A mature codebase that now has to meet regulation it was not written for |
| Long term partnership | Multi year, retainer | An embedded team inside your release process | A semiconductor vendor supporting a chipset family across its life |
If a supplier cannot map your problem onto a shape like this, with a duration and a named output, they are selling hours.
Deliverable one: chipset bring up and a stack that survives your silicon
The first thing that separates automotive BLE development from generic embedded work is that the partner has to work at silicon level rather than on top of a vendor SDK.
Bring up means getting the radio working on your board, with your antenna, your crystal, your power tree and your mechanical package, which behaves differently from the development kit in every one of those respects. The deliverables are a board support package, a validated RF configuration, and measured evidence that the radio meets its specification in the product rather than on a reference design.
The harder part is the stack above it. A vehicle programme usually needs more than one chipset across its life: a part goes end of life, a second source is required, or a variant needs a cheaper radio. A stack written directly against one vendor’s API has to be rewritten each time. A stack written against a hardware abstraction layer with a stable contract does not.
That is why a serious automotive BLE development services proposal talks about layered architecture and an operating system abstraction layer before it talks about features. It is also why the question “what happens when we change silicon” is the fastest way to find out how a supplier actually builds.
Deliverable two: the SDK, if you are the one shipping silicon
For semiconductor vendors the product is not a device, it is the developer experience of the customers designing your part in. That makes the SDK the deliverable, and it is a different discipline from writing firmware.
This is the part of automotive BLE development services that vendors most often underbuy. A production grade SDK covers layered architecture, a hardware abstraction layer, RTOS portability through an OS abstraction layer, disciplined memory management, security and Cyber Resilience Act readiness, an OTA update pipeline, build systems and CI/CD, documentation treated as a product, and a testing strategy. Nine areas, and a customer evaluating your chip will judge you on all of them within about a day of unpacking the kit.
The failure most often seen is an SDK shipped as a tarball with a README. It compiles, it demonstrates the feature, and then every chip customer’s first support call is about the build system. Documentation as code, reproducible builds and semantic versioning are not polish on top of an SDK. They are the parts your customers touch first.
Deliverable three: coexistence and RF that works in the product
A vehicle is a metal box containing Wi-Fi, cellular, BLE, often UWB, and a switching power supply, with the antennas packed into the same roof module, door or screen assembly.
Wi-Fi and Bluetooth share the 2.4 GHz band and cannot reliably detect each other. Wi-Fi occupies overlapping 20 or 22 MHz channels at up to +30 dBm, while Bluetooth uses 40 non overlapping 2 MHz channels at up to +20 dBm. The mitigation is packet traffic arbitration, hardware signalling between co located radios that scales from a one wire priority scheme up to four wires carrying REQUEST, GRANT, PRIORITY and FREQ, with request to grant delays of up to 255 microseconds.
The figure that ends arguments is antenna isolation. Higher Wi-Fi transmit power demands more isolation, and in space constrained packaging only 15 to 20 dB is not unusual. That is the number that decides whether your coexistence strategy is a configuration exercise or a mechanical redesign.
What automotive BLE development services should produce here is not an opinion. It is a measured coexistence report, taken with every radio active and loaded simultaneously in the final mechanical position, plus a documented arbitration configuration. A supplier who validated the radio on a development board in an open lab has not tested your product.
Deliverable four: the over the air update pipeline
Automotive over the air updates are where automotive BLE development services stop being a component and become infrastructure. Getting an automotive OTA update to a device is the easy half. Getting it there safely, provably, and without bricking anything is the deliverable.
The parts that matter:
Signed and verified firmware delivered over an encrypted channel and anchored in secure boot, so the update path strengthens the device rather than opening it. An update mechanism is an attack surface pointed directly at the thing you most want to protect.
Atomic A/B or dual bank updates with automatic rollback. The device writes to the inactive bank, verifies, then switches. A power loss or a corrupt image leaves the working firmware intact. Without this, an OTA software update automotive campaign is a fleet wide risk.
Staged rollout with canary releases and fleet telemetry, so a bad build reaches a hundred vehicles rather than a hundred thousand, and you find out from data rather than from a dealer.
Behaviour under constrained and intermittent links, which is the normal condition rather than the exception. A campaign has to survive a vehicle being switched off midway through a transfer.
Scale on the topology you actually use. Mesh OTA behaves differently from point to point, and a partner should be able to point at proven deployments rather than a theory. needCode has run OTA across 1,000 node BLE mesh networks, which is the kind of claim you should ask any supplier to substantiate with a number.
Deliverable five: UNECE R155 and R156 compliance is now the partner’s problem
This is the change most engineering teams have absorbed slowly, and it is the reason automotive over the air updates are no longer a feature decision.
UNECE R156 is the software update regulation for road vehicles. It requires manufacturers to operate an audited Software Update Management System, assessed at two levels. At organisational level you must show lifecycle management of updates: identifying target vehicles, checking compatibility, assessing impact, and delivering and documenting securely. At vehicle type level you must document the type approval relevant software configuration using the RXSWIN identifier, and assess whether each update changes an approved state.
R155 is its twin, covering cybersecurity through a Cybersecurity Management System. The regulations share an origin, deadlines and approval logic. R155 protects the vehicle from attack; R156 protects the update path itself. ISO/SAE 21434 is the recognised engineering framework beneath R155, and ISO 24089 plays the same role for R156.
| UNECE R155 | UNECE R156 | |
|---|---|---|
| Covers | Cybersecurity of the vehicle | The software update process |
| Management system required | CSMS | SUMS |
| Supporting standard | ISO/SAE 21434 | ISO 24089 |
| Vehicle type artefact | Threat analysis and risk assessment | RXSWIN, plus impact on approved state |
| Mandatory, new vehicle types | July 2022 | July 2022 |
| Mandatory, all new vehicles produced | July 2024 | July 2024 |
| Markets | UNECE 1958 Agreement states: EU, UK, Japan, South Korea. Not the USA, though European type approval makes it the de facto global benchmark | Same |
For type approval a manufacturer needs a CSMS certificate, a SUMS certificate, and component level certificates validated by an independent body. The SUMS certificate is valid for three years and is issued after an auditor from a UNECE listed inspection body examines whether the system meets the regulation. The regulation also requires that routines are defined for the case where an update fails, which is a requirement your rollback design either satisfies or does not.
The practical consequence for procurement is specific. If a supplier builds your BLE stack and your update path, their engineering artefacts become evidence in your audit. Configuration management, version traceability across ECUs and variants over years, signed release provenance and documented failure routines are not internal hygiene, they are the audit trail. Ask any automotive BLE development services supplier how their release process produces that evidence, and whether they have worked inside a SUMS before. If the answer is a blank look, you will be building the traceability yourself, after the fact, from git history.
The hardest part of R156 in practice is exactly that traceability: demonstrating which software versions run on which ECUs in which vehicle variants, and whether an update touches the approved state, end to end and across years.
Deliverable six: qualification and test automation
Two certification tracks run in parallel and people conflate them.
Bluetooth qualification is mandatory for every Bluetooth product before you sell or distribute it, and it is yours: a supplier or another member company cannot qualify your product on your behalf. Products that appear not to have completed it can be impounded by customs and are subject to Bluetooth SIG enforcement. Regulatory type approval under R155 and R156 is a separate process with separate evidence.
| Track | Who owns it | What it produces | When it bites |
|---|---|---|---|
| Bluetooth SIG qualification | You, never the supplier | Declaration ID and a listing | Before first sale or distribution |
| UNECE R155 | The vehicle manufacturer | CSMS certificate | Type approval, then every new vehicle |
| UNECE R156 | The vehicle manufacturer | SUMS certificate, valid three years, plus RXSWIN | Type approval, then every update that touches approved state |
| Automotive grade silicon | Silicon vendor, verified by you | AEC-Q100, HTOL, mission profile data | Component selection, years before launch |
What automotive BLE development services deliver against this is automation. Running the Bluetooth Profile Tuning Suite by hand takes a senior engineer one to two weeks for a non trivial device, which means most teams run it once per release and find specification regressions late, under deadline pressure, with several changes stacked on top of the cause. Automated PTS runs turn that into an overnight job, alongside hardware in the loop rigs exercised per commit, RF and protocol test automation under controlled propagation, and reproducible Docker based builds.
The test rig is a deliverable in its own right. If it leaves with the supplier, you bought hours.
How to tell a delivery partner from a body shop
Six questions to put to any automotive BLE development services supplier, each with a wrong answer that is easy to hear.
What do we hold at the end, and can our team run it without you? Look for named artefacts, not a headcount.
What happens when we change silicon? Look for an abstraction layer that already exists, not a promise to refactor.
Show me a coexistence report from a product, not a development board. Look for measurements in the final mechanical position with every radio loaded.
Walk me through your OTA failure matrix. Look for power loss during flash write, corrupt image, interrupted transfer and rollback, not a happy path demo.
How does your release process produce R156 evidence? Look for version traceability and signed provenance as a normal output, not something to be assembled later.
Who owns the Bluetooth qualification and the test rig? Look for you, and you.
Where needCode fits
needCode delivers automotive BLE development services as scoped engagements rather than staff hours: chipset bring up, layered stack and SDK design, coexistence architecture, OTA pipelines and test automation through to qualification. The team works across Nordic nRF54 and nRF53, including BLE Channel Sounding with phase based ranging at sub metre accuracy, Qorvo QM33 and QM35, and NXP, STMicroelectronics, Infineon and Silicon Labs parts. needCode is a certified Qorvo partner of more than eight years, a Nordic Semiconductor Design Partner for EMEA, and a UWB Alliance member, and holds ISO/IEC 27001:2022 and ISO 9001:2015.
Engagements follow the four shapes in the table above, and most vehicle programmes start with the two to four week audit, because it produces a roadmap you can act on with or without us. Our automotive and SDV practice covers digital key, secure ranging, in cabin sensing and OTA as one programme rather than four, which matters when the same radio serves several functions and the update path has to carry all of them.
One thing we will say plainly: needCode is an embedded wireless specialist, not a Tier 1. If your programme needs a supplier who takes production responsibility for a module, that is a different kind of company. If it needs the firmware, the RF work and the evidence trail to be right, that is us.
If you are scoping the connectivity layer of a vehicle programme, book a discovery call.
Frequently asked questions
At minimum: chipset bring up on your hardware, a layered BLE stack with a hardware abstraction layer so the design survives a change of silicon, RF and coexistence validation in the final mechanical package, an over the air update pipeline with signed images and rollback, test automation including automated Bluetooth Profile Tuning Suite runs, and the documentation and version traceability that a UNECE R156 audit will ask for. The distinguishing question is whether these arrive as artefacts you keep and can run yourself, or as activity you rent. A delivery engagement leaves you with a stack, a test rig, a qualification submission and an update pipeline. A staff augmentation engagement leaves you with people who leave, which is a legitimate model for a multi year chipset programme but a poor fit for shipping one product.
The regulation binds the vehicle manufacturer, not you directly, but your work becomes their evidence. R156 requires an audited Software Update Management System covering identification of target vehicles, compatibility checking, impact assessment on type approval, secure delivery and documentation, plus RXSWIN configuration management at vehicle type level. If your firmware ships in an approved vehicle, your version traceability, release provenance and update failure routines all feed that audit. In practice this means an OEM customer will pass requirements down to you contractually. Suppliers who already produce that evidence as a normal output of their release process are considerably cheaper to work with than ones who have to reconstruct it from git history after the fact.
Both became mandatory for new vehicle types in July 2022, and for all newly produced vehicles including existing types in July 2024. They apply across UNECE 1958 Agreement contracting states, which includes the European Union, the United Kingdom, Japan and South Korea, but not the United States. Because European type approval requires compliance, they function as the de facto global benchmark regardless. R155 covers cybersecurity through a Cybersecurity Management System, with ISO/SAE 21434 as the supporting engineering framework. R156 covers the software update process through a Software Update Management System, with ISO 24089 in the equivalent role. Type approval requires a CSMS certificate, a SUMS certificate valid for three years, and component certificates validated by an independent body.
You are, and this is not negotiable. The Bluetooth SIG is explicit that a supplier or another member company cannot qualify your product on your behalf. Qualification must be completed on or before the date you begin to sell or distribute, and products that appear not to have completed it can be impounded by customs authorities and are subject to enforcement action. What a development partner can do is prepare the submission, run the testing, and automate the regression so the qualification state is known continuously rather than discovered before a launch. Automated Profile Tuning Suite runs turn a one to two week manual regression into an overnight job, which is the difference between qualification being a scheduled event and a fire drill.
Ask what you hold at the end and whether your own team can run it without them. Then ask four specifics. Ask what happens when you change silicon, and look for an existing abstraction layer rather than a promise to refactor. Ask to see a coexistence report from a product rather than a development board, measured in the final mechanical position with every radio active and loaded. Ask them to walk through their over the air update failure matrix, covering power loss during a flash write, corrupt images, interrupted transfers and rollback, not the happy path. Ask how their release process produces R156 evidence as a normal output. Suppliers selling hours tend to answer these with team size and seniority. Suppliers who deliver answer with artefacts.
